Je recherche un moyen léger, rapide et facile de gérer la communication entre les processus entre certains programmes sur une machine Linux.
Actuellement, je pense que le tuyau nommé, car il est fourni par le système d'exploitation lui-même. Y a-t-il des mises en garde sur la performance ou la convivialité?
serait mieux que la mémoire?
Je ne pense pas avoir besoin d'un cadre super complexe.
Merci de me signaler dans la bonne direction, merci!
mise à jour: Je veux construire un petit programme (démon) qui indique à d'autres programmes (qu'il commence elle-même) de faire une pause, de rapporter son statut, d'arrêter, etc.
L'autre programme doit donc être informé qu'une nouvelle commande l'attend. Un tuyau n'est pas idéal pour ça, est-ce?
6 Réponses :
Boost a une belle Interprocess bibliothèque qui est une plate-forme croisée et assez intuitive.
Je n'ai joué que avec elle, alors il pourrait y avoir de meilleures alternatives là-bas.
Cependant, si vous n'avez pas vraiment besoin de mémoire partagée, j'en collerais avec une approche de messagerie. Vous éviterez des blocages et des conditions de course. Le principe de tuyau est vraiment génial et il permet même des comportements paresseux qui peuvent vous économiser beaucoup de traitement en fonction de la question à portée de main!
Ça a l'air intéressant. Je vais y jeter un coup d'oeil. Je semble toujours oublier de regarder les bibliothèques de boost.
Comme vous l'avez vu, vous pouvez utiliser la communication entre les processus:
La mémoire partagée présente l'avantage des performances, car vous n'avez pas de mémoire tampon lors de l'envoi / de la réception de messages. Mais vous devez synchroniser vos échanges de données avec une autre IPC. Il peut être des sémaphores IPC ou ... des tuyaux ou des sockets nommés.
Lorsque la performance n'est pas l'objectif principal, j'ai tendance à préférer les sockets car leur utilisation est simple et peut être étendue à la communication intermédiaire.
Le meilleur moyen est de résumer votre communication avec une classe pouvant utiliser la mémoire partagée lorsque les deux processus sont sur le même ordinateur et les mêmes prises, sinon. Ensuite, vous devez choisir entre UDP et TCP; -)
pour l'échange synchro / tampon, préférez TCP comme il est plus fiable.
Je n'utilise pas de tuyaux nommés comme je préfère la prise de la possibilité d'utiliser Inter Computer Communication et bien sûr, vous pouvez trouver de nombreuses bibliothèques de prise portable ...
my2cents
EDIT:
Pour la synchronisation, MEM partagé n'est peut-être pas le meilleur outil. Dans votre cas, il peut être utilisé en partageant un petit espace mémoire, avec un espace pour chaque processus attendant les commandes. Vous pouvez sonder un sondage pour toute commande incommodé ou utiliser un sémaphore partagé. Le moyen le plus rapide est que vos processus attendent des sémaphores nommés et de lire un espace MEM partagé pour leurs commandes / paramètres. L'utilisation de tuyaux nommés est sûrement plus simple mais pas si rapide. Vous n'avez sûrement pas besoin d'être si rapide? Quoi qu'il en soit, abstrait que dans une classe qui modélise votre protocole d'échange et essayez les deux manières: -)
J'aimerais avoir quelque chose sans utiliser la pile de pile TCP, car une performance optimale est nécessaire. Nous allons également utiliser TCP pour la communication avec d'autres machines, mais également quelque chose de plus rapide serait idéal.
@brandstaetter: Dans ce cas, MEM partagée est la voie. Plus les données sont grandes, mieux le gain de performance. Autre IPC (et socket) doit faire tamponner, même s'ils sont optimisés. Avec MEM partagé, vous êtes sûr qu'il n'y a pas de tampon au-dessus de la tête. Nous utilisons MEM partagé pour l'échange d'images. Le synchro peut être effectué avec un tuyau nommé ou une prise (locale), plus facile à gérer que le sémaphore partagé (et plus portable). Vous pouvez même faire sans dépendre de votre protocole de données / échange ...
@Matthieu: Merci. Cela prouve toujours une bonne chose de particularité lorsqu'il s'agit d'une interface externe :-)
D-BUS est assez utile et très stable de faire de l'IPC dans le même hôte. http://www.freedesktop.org/wiki/software/dbus
Hum, un peu surkill et je suppose qu'il est difficile de configurer si pas déjà installé / configuration?
J'utiliserais des prises UNIX ou une bibliothèque qui les enveloppe. Les prises UNIX sont assez faciles à utiliser.
D'autre part Si vous avez des informations sur l'état de taille fixe à rapporter, vous pouvez simplement avoir les processus enfants à l'écrire dans un fichier (probablement il est petit et vous ne pourrez pas que cela ne produira pas de manière significative. Charge de travail io).
+1: Oui Pourquoi pas un fichier. Pas la meilleure façon en ce qui concerne le synchro, mais vous pouvez utiliser un marqueur / compteur pour la synchronisation.
La mémoire partagée avec des sémaphores est la plus rapide et la plus transparente si vous souhaitez créer des logiciels directement à partir des primitives.
Les tuyaux nommés ne sont pas trop différents des tuyaux et fonctionnent bien entre une paire de processus et non un serveur et de nombreux clients.
Si vous aimez construire sur l'infrastructure existante, DBU est une option.
La communication de la prise est polyvalente et évitent bien si vous souhaitez déplacer vos applications sur des hôtes sur un réseau.