Bonjour à tous,
 
J'ai écrit un bout de code dans mon appli en utilisant les messages queues fournies par la lib real time (librt) du système sous linux, je teste le bouzin et ça ne marche pas. Je tâtonne, je cherche un peu sur le net, et finalement je découvre que l'API n'autorise l'utilisation que de 10 messages par queue...
 

   
 
La structure mq_attr permet de définir mq_maxmsg le nombre de message de la queue, si par malheur on en définit plus de 10 mq_open échoue avec un "invalid argument"...
 
Le #define MQ_MAXMSG n'est documenté nulle part, ce n'est qu'en cherchant sur le net que j'ai trouvé d'autres personnes qui ont rencontré le problème. Le plus étonnant c'est qu'on trouve sur le net d'autres version de la lib qui définissent MQ_MAXMSG à 40, ou à 100. Pourquoi cela n'est-il pas normalisé? Pour ma part mon système possède la librt-2.3.4.so, mais mon appli doit fonctionner sur d'autres machines. Je vais partir sur une autre solution mais j'aurais aimé comprendre cette aberration de fixer un paramètre aussi important dans une lib aussi commune...

up

Attention, ça ne marche que mq_open de changer mq_maxmsg.

Parce que c'est une valeur par défaut sans grande importance ? Si tu veux plus, demande plus.
 
T'as tout dans le man, y compris le sysctl /proc pour avoir une valeur supérieure à 10.

 
Je comprends pas la phrase mq_open plante avec invalid argument :
 

 
 
Ok je check baby

Je sais que t'as raison, laisse moi chercher.

Mais en fait ça me fait chier si je dois régler le nombre max de messages depuis le système, en root à tous les coups, c'est pas très user compliant Comment je fais si je veux distribuer mon appli et être sûr que ça plantera pas à l'exécution?

Patapay je cherche toujours le sysctl /proc

minable ta non-initialisation de struct ... soit fais un memset, soit fais un simple "attr = { 0, 1, 2, 3 };" pour être sur que tous les membres que tu n'initilises pas sont à 0 plutôt qu'à des valeurs délirantes.
 
Si t'as besoin d'une taille plus grande:
- tu peux la vérifier en lisant /proc ou quand tu crées ta file, tu vois bien si ton open marche avec la valeur que tu demandes ou pas
- quand la file est pleine, ça bloque, à moins que tu mettes un flag pour que ça ne bloque pas, auquel cas, tu peux ressayer plus tard.

>>T'as tout dans le man, y compris le sysctl /proc pour avoir une valeur supérieure à 10.  
 
ok bon ça j'ai pas trouvé où tu l'avais vu dans le man de mq_
 
 
sysctl on peut le faire depuis le code, mais bon toucher au noyau c'est pas très à propos dans mon appli, je pense que j'avais fait fausse route en utilisant ça.

C'est toi t'es minable

- Je veux pas vérifier si ma valeur >10 que je demande marche, je veux que ça marche avec 100 messages par file
- HS

Mais merci pour ton intervention, j'y vois plus clair, et je me sens un peu plus crétin

Nan mais je pense que ton erreur, c'est juste un bug de données pas initialisée ...
 
10 ou 100, c'est le même problème, si tu ne gères pas le cas où la file est pleine, ça fera tot ou tard des surprises. C'est dans le manuel, 100 ça ne marchera pas avec les valeurs par défaut système. La taille totale de la file faut pas l'oublier non plus.

Je vois pas de bug dans mon initialisation :
 

 
mq_flags ça va changer quelque chose au moment d'envoyer/lire des messages, moi ça plante quand je fais un mq_open avec mq_maxmsg = 11.
 
mq_curmsgs faut pas l'initialiser si je ne m'abuse.
 
Je poste mon de code de test

 
Et les autres membres, ils valent quoi ? UB.

avec #define MAXMSG   11 ça plante avec "Ca plante à l'ouverture: Invalid argument"
avec 10 ça passe.
Mon code est beau.

gcc -Wall -pedantic -ansi -lrt mqueue.c

1) et le flag, il prend quelle valeur ?
2) voir premier message. Il faut augmenter la limite système.

'tain t'es chaud de créer ta propre fonction send ... man 2 send

J'ai tout initialisé mais sans succès

Et quand je te parlais de taille de file.
 
 
SUPERGRAND 1000000
 
ça fait du bon bourrage de pile par la suite. Etant donné que la taille des messages/files est bien plus petite que ça

 
 
1) on s'en fout du flag, il sert pas à l'ouverture mais à l'envoi
2) c'est bien ce que j'avais compris, je veux pas toucher au système donc c'est DMC.

Et manie le perror/strerror/errno pour pouvoir qualifier les -1 retournés, sinon tu peux pas savoir pourquoi ça ne marche pas.

 
 
On s'en fout aussi, c'était pour mes tests perso, bien évidemment ceci n'est pas le logiciel que je développe professionnellement pour mon employeur.

1) ok j'avais pas lu. Ca reste pas idiot d'utiliser généralement la syntaxe d'initialisation.
 
Je comprends pas pourquoi tu bloques vraiment sur la taille de la file. Si elle est pleine, bah tu bloques dessus jusqu'à qu'un autre processus la vide.

 
je rêve ou tu me parles de socket là? J'ai pas écrit de fonction send, y'a rien dedans.
 

 
Comme je l'ai dit mon code est magnifique

Bah on s'en fout oui et non, à force de faire des trucs foireux/baclés pour tester, ça devient dur de savoir si ton test marche ou pas.

 
 
Parce que je bosse sur un simulateur temps réel qui n'a pas le temps d'attendre que la file se vide. Donc j'en reviens à la conclusion que cette API n'est pas faite pour moi.

(T'as aussi écrit une close. C'est des mauvaises habitudes à ne pas prendre sinon un jour tu le feras vraiment et tu comprendras jamais pourquoi ça marche pas).

Bah t'as le flag d'open et le flag de receives/send qui te permet de ne pas attendre

 
J'ai pas compris, qu'est-ce que j'ai fait ?  
 
 

 
Oui mais ne pas attendre signifie que le send échoue et qu'il faut revenir poster les messages qui ne sont pas passés, moi j'aimerais poster tous mes messages pis continuer à faire autre chose quoi.

Je comprends, mais si tu penses comme ça, tu vas avoir le problème tous les appels systèmes et fonctions qui se sont pas async (à commencer par le moindre read ou write).
 
Soit tu gères dans une boucle le fait que la file soit pleine, soit tu le traites dans un autre thread ou dans un sous-programme chargé de poster.
 
C'est sans fin comme problème.
 
Empiler encore et encore côté envoyeur, ça ne résout pas forcément ton problème puisque y a forcément une limite à un moment et c'est un peu inquiétant que ça ne vide pas au bon rythme en face ?
 
 
C'est du producteur/consommateur de base en IPC: mq, pipe ou autre le système est pas là pour stocker tous tes messages. Il te donne de tuyaux de taille fixe, si tu veux bufferiser plus, il faut que tu le fasses toi même côté utilisateur.

J'ai compris ce que tu m'expliques, mais dans mon cas le nombre de messages envoyés a une limite max, c'est dans la spec.  
 
De plus je ne suis pas rentré dans le détail dans mon post mais pour le moment je n'ai qu'un seul processus, l'envoi se fait à t0 et la réception se fait à t1 dans un callback appelé par un échéancier. En bref je me suis fourvoyé avec cette lib, je vais utiliser un buffer circulaire et pis ça ira tout seul.

Ca c'est sur que si c'est pas threadé ni multiprocessé, c'est pas bien la peine de sortir faire de l'IPC. Si ça se trouve, t'as peut-être meme pas besoin de synchronisation.
 
Comme tu dis, un pauvre buffer, de la synchro comme il faut, et ça doit se faire tout seul. Réfléchi bien à la synchro si c'est 2 thread qui communiquent pour faire quelque chose d'intelligent

Bein c'est parce que potentiellement un jour ce sera multithreadé que j'ai utilisé ça, donc je voulais déjà le valider.
 
Bon bein thx

c'est pour de la comme entre processus ça.

c'est ce que je voulais dire

 
 
Au fait ça veut dire quoi UB? Tu m'as insulté?  

Tu te fous de la gueule de mon pote?

suce moi papa!