2009-08-05 4 views
4

J'ai un projet qui se compose de deux processus et j'ai besoin de transmettre des données entre eux de manière rapide et efficace. Je suis conscient que je pourrais utiliser des sockets pour cela en utilisant TCP, même si les deux processus existeront toujours sur le même ordinateur, mais cela ne semble pas être une solution très efficace.C++ processus multiples?

Je vois beaucoup d'informations sur l'utilisation de "pipes" sous Linux. Cependant, je veux principalement cela pour Windows et Linux (de préférence via une bibliothèque multi-plateforme), idéalement dans un coffre-fort de type, de manière non-bloquante.

Une autre chose importante est que je dois prendre en charge plusieurs instances de l'application entière (c'est-à-dire les deux processus), chacune avec sa propre copie indépendante des objets de communication.

Existe-t-il également une méthode multiplateforme pour engendrer un nouveau processus?

Répondre

7

Pour IPC, Windows supports named pipes, tout comme Linux does, sauf que les noms des tuyaux suivent un format différent, en raison de la différence de formats de chemin entre les deux systèmes d'exploitation. C'est quelque chose que vous pourriez surmonter avec de simples définitions de préprocesseur. Les deux systèmes d'exploitation prennent également en charge les E/S non bloquantes sur les conduites et le multiplexage E/S avec select().

1

Il peut s'agir d'une surcharge, mais vous pouvez utiliser Apache Portable Runtime; here sont les fonctions de thread et de processus.

12

Jetez un oeil à Boost.Interprocess

Boost.Interprocess simplifie l'utilisation des mécanismes de communication et de synchronisation interprocessus commun et offre un large éventail d'entre eux:

  • Mémoire partagée.
  • Fichiers mappés en mémoire.
  • Sémaphores, mutex, variables d'état et types de mutex pouvant être mis à niveau pour les placer dans la mémoire partagée et dans les fichiers mappés en mémoire.
  • Versions nommées de ces objets de synchronisation, similaires à UNIX/Windows sem_open/CreateSemaphore API.
  • Verrouillage de fichier.
  • Pointeurs relatifs.
  • Files d'attente de messages.

Boost.Interprocess propose également des mécanismes interprocessus de niveau supérieur pour allouer dynamiquement des parties d'une mémoire partagée ou d'un fichier mappé en mémoire (en général, de répartir des portions d'un segment de mémoire de taille fixe). L'utilisation de ces mécanismes, Boost.Interprocess offre des outils utiles pour construire des objets C++, y compris les conteneurs STL-like, dans la mémoire partagée et la mémoire des fichiers mis en correspondance:

  • création dynamique d'objets anonymes et nommés dans une mémoire partagée ou d'un fichier de mémoire mappée .
  • Conteneurs de type STL compatibles avec les fichiers de mémoire partagée/mappés en mémoire.
  • Allocateurs de type STL prêts pour la mémoire partagée/fichiers mappés en mémoire implémentant plusieurs modèles d'allocation de mémoire (comme la mise en pool).

Boost.Interprocess a été testé dans les compilateurs suivants/plates-formes:

  • visuel 7.1 visuel Windows XP
  • 8.0 Windows XP
  • GCC 4.1.1 MinGW
  • GCC 3.4.4 Cygwin
  • Intel 9.1 Windows XP
  • GCC 4.1.2 Linux
  • GCC Solaris 11
  • 3.4.3
  • GCC 4.0 MacOs 10.4.1
+2

boost :: interprocess a une implémentation fictive sur Windows qui utilise des temps d'attente pour tout. Je ne le recommanderais pas moi-même. – bdonlan

2

Plain Old TCP devrait fonctionner assez efficacement; si je comprends bien, les systèmes d'exploitation modernes détecteront lorsque les deux extrémités d'une connexion TCP sont situées sur la même machine et achemineront ces données en interne via un mécanisme rapide (léger) plutôt que par la pile TCP ordinaire. Donc, si vous avez déjà du code qui fonctionne sur TCP, je vous en dis un peu plus et vous éviterez de passer beaucoup de temps de développement pour peu de gains.

+0

Quel système d'exploitation fait ce que vous avez dit? S'il vous plaît partager w/moi. – Test

+0

Si Linux, je suis sûr que non, parce que les paquets pourraient être capturés par tcpdump tandis que 2 se termine sur la même machine. – Test

+0

Mon post est basé principalement sur une conversation que j'ai eu avec RobSeace sur le site Unix Sockets FAQ, vous pouvez le lire ici: http://www.developerweb.net/forum/showthread.php?t=5154 En particulier, cette citation de Rob: «Oui, les sockets de domaine Unix seraient beaucoup plus efficaces, en contournant une grande partie de la pile de TCP/IP du noyau qui n'est pas nécessaire avec IPC local ... (Bien que, si vous utilisez 127.0.0.1, la plupart les systèmes modernes devraient aussi optimiser l'interface de bouclage ...) " –