Inter process communication

Salut à tous !
Je viens à vous pour obtenir quelques conseils à propos de la communication inter-processus sous Linux.
Mon souhait est d'implémenter une solution portable et la moins restrictive possible pour communiquer sans encombres entre deux processus indépendants.
Apparemment il y a pas mal de façons de faire , sémaphore, "pipe name " (restrictive sur la longueur des messages apparemment ... ), les queues ....

J'aimerai l'avis de quelques spécialistes pour partir dans la bonne direction....
La solution du sémaphore me parait peut-être la plus adaptée (mais en même temps c'est la seule que je connaisse clairement ... ). Je cherche avant tout la portabilité.

Voilà ! Merci pour vos lumières !

tout dépend communiquer quoi, avec quelles contraintes..

Tu as aussi mémoire partagée, sockets, etc etc..

j'aimerais communiquer à un processus le fait qu'un autre processus indépendant a subit une action et faire savoir que ça tache est bien terminée pour que le premier processus puisse ensuite effectuer sa tache...
En fait Dès que le second processus a effectuer sa tache il faudrait qu'il puisse avertir le premier. Mes deux processus sont sensés être complètement indépendants....

qu'est ce que tu souhaites en terme de portabilité : inter-unix ou unix/windows ? choisir la solution posix serait le plus sage a mon avis.
intrinsèquement parlant tu souhaites 'synchroniser' l'exécution de tâches et non faire des échanges de données.
dans ce cas utilise les semaphore/mutex (il y a un cours bien fait dans la section linux de developpez.com).
si tu veux un fonctionnement complètement asynchrone alors il te faudra utiliser par exemple les signaux pour notifier un processus d'un evènement particulier et exécuter un code en particulier.

je cherche pour commencer une portabilité inter-unix et effectivement les processus fonctionneront sur un mode asynchrone, d'autre part il me faudrait également un échange de données entre les deux processus.

Citation:

---

Envoyé par swingNJava

j'aimerais communiquer à un processus le fait qu'un autre processus indépendant a subit une action et faire savoir que ça tache est bien terminée pour que le premier processus puisse ensuite effectuer sa tache...
En fait Dès que le second processus a effectuer sa tache il faudrait qu'il puisse avertir le premier. Mes deux processus sont sensés être complètement indépendants....

---

Si tu dis qu'un processus attend qu'un autre termine sa tache pour realiser une action alors tu les synchronises par une sémaphore. L'exécution de l'un sera suspendu jusqu'à ce que l'autre libère le sémaphore.
Tu as une explication et des exemples ici

Si cela ne te convient pas je te prierai d'expliquer pourquoi et surtout de préciser ta question. Merci.

Merci pour toutes ces réponses ! Après quelques tests, je suis convaincus que les sémaphores représentent une solution simple et portable sur les unixoïdes pour la synchronisation. La dernière question que je me pose est comment communiquer des données de l'un au l'autre ? par exemple envoyer le résultat du processus attendu à celui en attente..... toujours dans un soucis de propreté et de portabilité ...
Merci !

Tu as pleins de méthodes tout dépend de la façon dont tu souhaites les faire communiquer et synchroniser les données, ainsi que leur nature.
mettons par exemple une structure :
_ socket unix
_ queue de message
_ mémoire partagés
_ Tubes nommés (jamais utilisé)
...

toutes on un avantage/inconvenient, a toi de faire le choix selon la façon dont tu souhaites traiter les données.
Avec les sockets tu auras une architecture de comm du type serveur/client. A etudier la bufferisation des données non lues.
Avec les queues de messages : la comm est tout a fait asynchrone, la donnée consommée disparaît. A Etudier : les variations consommation/production de données : tes queues vont se remplir plus ou moins vites. Tu peux donner des priorités à tes messages.
Mémoire partagée : la taille de la ressource occupée est fixée dès le départ. Les processus sont complètement indépendant pour l'
utilisation de cette ressource. Les processus doivent connaître le codage des données dans cette mémoire. Dans certains cas Il te faudra préserver l'intégrité des données avec une sémaphore. Si tu codes une structure dans cette mémoire, tu ne liras que les dernières modifications, contrairement à une queue de message.

Tu peux voir le cours qui explique ces objets systèmes dans le lien que je t'ai passé auparavant.
++

Citation:

---

Envoyé par bizulk

Tu as pleins de méthodes tout dépend de la façon dont tu souhaites les faire communiquer et synchroniser les données, ainsi que leur nature.
mettons par exemple une structure :
_ socket unix
_ queue de message
_ mémoire partagés
_ Tubes nommés (jamais utilisé)
...

toutes on un avantage/inconvenient, a toi de faire le choix selon la façon dont tu souhaites traiter les données.
Avec les sockets tu auras une architecture de comm du type serveur/client. A etudier la bufferisation des données non lues.
Avec les queues de messages : la comm est tout a fait asynchrone, la donnée consommée disparaît. A Etudier : les variations consommation/production de données : tes queues vont se remplir plus ou moins vites. Tu peux donner des priorités à tes messages.
Mémoire partagée : la taille de la ressource occupée est fixée dès le départ. Les processus sont complètement indépendant pour l'
utilisation de cette ressource. Les processus doivent connaître le codage des données dans cette mémoire. Dans certains cas Il te faudra préserver l'intégrité des données avec une sémaphore. Si tu codes une structure dans cette mémoire, tu ne liras que les dernières modifications, contrairement à une queue de message.

Tu peux voir le cours qui explique ces objets systèmes dans le lien que je t'ai passé auparavant.
++

---

J'arrive un peu tard (comment ai-je raté ce topic ???) mais je peux apporter quelques précisions
- les socket => l'avantage c'est que le protocole est analogue au protocole TCP/IP => tu pourras plus tard faire évoluer ton code pour qu'il traverse le réseau
- queues de messages et mémoire partagée => utile s'il n'y a pas unité de temps entre l'écriture et la lecture => le processus écrivain peut avoir disparu depuis des jours, la donnée est toujours présente pour une lecture. La file de message permet en plus de rajouter une mécanisme simpliste de "tri" des informations que ne permet pas la mémoire partagée.
- tubes nommés => la base de la communication entre processus Unix. Un processus ouvre le tube pour écrire dedans et l'autre va lire les données écrite. On pourrait faire pareil avec un simple fichier mais le tube offre l'avantage d'apporter un mécanisme automatique de verrou

Voir les cours et tutoriels Linux : http://linux.developpez.com/cours/