Discussion :

[Ashin]

Bonjour,

J’aimerai savoir quel type d’IPC utiliser pour mon application. Je m’explique :

J’ai deux applis qui actuellement communiquent par queues de messages (sysV) et j’aimerais changer le types d’IPC afin de gagner en vitesse sans toutefois perdre en stabilité. Les données échangées ne dépassent pas 3950 octets.

La première appli démarre puis se forke, ensuite le fils créé plusieurs messages queues fait son taff, supprime les queues puis meurt, le père reforke le nouveau fils créé plusieurs queues …

Qu’en pensez vous ??
Merci

edit: systèmes: RHEL 4 et Solaris 8

[Ashin]

les IPC n'intéressent personne

[Sve@r]

La première appli démarre puis se forke, ensuite le fils créé plusieurs messages queues fait son taff, supprime les queues puis meurt, le père reforke le nouveau fils créé plusieurs queues …

Si les data ne sont traitées que par un même fils, pas besoin d'IPC.

Maintenant, si les msq sont trop longues pour toi et que ton souci est la rapidité, alors te faut utiliser les shm.
En fait, le seul avantage d'une msq c'est qu'il y a un identificateur numérique permettant un certain type de sélection. Tu peux entrer une data numéro 1, une data numéro 2, une autre numéro 2 et une 4° numéro 1, si tu demandes ensuite les numéro 1 tu récupèreras la 1° et la 4°.
Un autre avantage (qui peut aussi ne pas l'être selon la façon de voir) est qu'une data récupérée est automatiquement effacée.

Avec la shm, tu places simplement des octets dans une map que tu viens lire quand tu veux. C'est ce qu'il y a de plus rapide. Généralement on la couple avec un sem pour éviter les accès concurrents mais si t'en as pas besoin...

[Ashin]

je me suis mal exprimé, en fait le fils créé des queues pour communiquer non pas avec son père mais avec un autre process. Le père est seulement là en cas de problème (lors de la comm ou autre) et que le fils se plante.

donc en gros, pour simplifier ça revient à deux process qui communiquent par mq

[Sve@r]

je me suis mal exprimé, en fait le fils créé des queues pour communiquer non pas avec son père mais avec un autre process. Le père est seulement là en cas de problème (lors de la comm ou autre) et que le fils se plante.

donc en gros, pour simplifier ça revient à deux process qui communiquent par mq

Ok. Ben ils peuvent communiquer aussi
- par socket mémoire => le père crée la socket et chaque fils lit ou écrit le coté qui va bien
- par socket fichier => idem
- par shm => le père crée la shm et chaque fils la rattache à un pointeur perso puis ensuite les fils y vont allègrement à coup de memcpy()

[Ashin]

actuellement j'hésite entre socket local et pipe nommé (FIFO) qui sont moins lourds

[Sve@r]

actuellement j'hésite entre socket local et pipe nommé (FIFO) qui sont moins lourds

Sûrement pas. Les pipes nommés (fichier de type "p") nécessitent un accès disque. Ils ne sont certainement pas "moins lourds" que les pipes mémoire (surtout si tu prépares bien ton truc, avec une structure permettant de manipuler facilement le pipe...)
Et ces deux outils étant contrôlés par le noyau (verrouillage des processus jusqu'à synchronisation), consomment forcément du temps cpu (temps utilisé pour le contrôle), temps qui n'est pas consommé par les shm puisque celles-ci ne sont pas contrôlées (tu parlais au début de rapidité...)

[Ashin]

oui mais on ne peut pas utiliser les pipes mémoires s'ils n'ont pas la même racine, non ?

[Sve@r]

oui mais on ne peut pas utiliser les pipes mémoires s'ils n'ont pas la même racine, non ?

Exact. Mais la shm est accessible par tout le monde (pour peu que chacun connaisse la clef)...

[Ashin]

je vais tester les shm aussi alors, mais bon s'il faut que je les couple avec des sems, je pense pas être plus rapide que les sockets

[Sve@r]

mais bon s'il faut que je les couple avec des sems, je pense pas être plus rapide que les sockets

Ah non. J'ai dit que "généralement" on les couple avec les sem pour éviter les problèmes de data incorrecte (data lue alors qu'un autre process est en train de la modifier) mais si ce cas est peu probable ou pas grave, tu peux très bien éviter les sem !!!