Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Communication entre deux processus via subprocess

7 réponses
Avatar
Jonathan Barnoud
Bonjour, je cherche à faire communiquer deux processus via les entrées
et sorties standard. L'un est le processus parent écrit en python. Il
peut être tordu ce n'est pas un problème. Il appelle se second processus
comme processus-enfant, ce denier pouvant être écrit dans n'importe quel
langage et devant être le plus simple possible.

J'avais pensé m'en sortir avec subprocess pour le parent et de simples
print et input pour l'enfant. Sur un exemple simple ça a l'air de marcher.

### parent.py
#!/usr/bin/env python
#-*- coding:utf-8 -*-

import subprocess

enfant = subprocess.Popen("./enfant.py", stdin=subprocess.PIPE,
stdout=subprocess.PIPE)
enfant.stdin.write("toto\n")
###

### enfant.py
#!/usr/bin/env python
#-*- coding:utf-8 -*-

output = open("output", "w")
output.write(raw_input() + "\n")
output.close()
###

Toutefois, le but n'est pas de transmettre "toto" du parent à l'enfant.
L'enfant doit attendre un signal du parent lui indiquant que c'est son
tour puis envoyer un certain nombre d'instructions dont il attend une
réponse, enfin envoyer un signal comme quoi il a fini de causer pour son
tour et attendre à nouveau son tour.

Mes essais étant très franchement infructueux, je me demandais si ce que
je cherchais à faire était seulement réalisable.

Si vous avez la moindre idée...

Jonathan Barnoud

7 réponses

Avatar
Méta-MCI \(MVP\)
Bonsoir !

Pour faire de l'IPC (Inter-Processus-Communication), j'utilise les
voies suivantes :
- COM, si un des processus est serveur COM accessible par l'autre
- COM, via un serveur COM commun et persistant (j'ai créé PBridge
pour cela).
- mmap, avec partage d'une zone mémoire de type fichier
- TCP/IP, avec éventuellement un mini-serveur relais (avantage, ça
fonctionne aussi en réseau, ou via Internet, si l'on peut configurer
routeurs et parefeux)
- mailslot (peut fonctionner entre plusieurs processus d'un poste,
mais aussi en réseau local)
- messages inter-fenêtres (surtout WM_COPYDATA ; pour certaines
applications qui gèrent cela).
Plus quelques autres moyens particuliers, propres à certaines
applications.

Tout cela fonctionne bien sous Windows. Comme tu n'as pas précisé, j'ai
pris la liberté de choisir.
Cependant, quelques-unes devraient fonctionner sous linux, Mac, ou
Windows et ces OS.
Dernières possibilités, qui me semblent intéressantes :
- voir Pyro ;
- voir XMLRPC
(les deux fonctionnent localement et en réseau).

Le choix devra aussi tenir compte de la vitesse souhaitée. Par exemple,
avec COM, je dépasse allègrement les 10000 appels par seconde. Mais,
avec TCP/IP, difficile de faire mieux que 50 à 100 /s (en réseau local).


@-salutations
--
Michel Claveau
Avatar
Jonathan Barnoud
Méta-MCI (MVP) a écrit :
Bonsoir !

Pour faire de l'IPC (Inter-Processus-Communication), j'utilise les
voies suivantes :
- COM, si un des processus est serveur COM accessible par l'autre
- COM, via un serveur COM commun et persistant (j'ai créé PBridge
pour cela).
- mmap, avec partage d'une zone mémoire de type fichier
- TCP/IP, avec éventuellement un mini-serveur relais (avantage, ça
fonctionne aussi en réseau, ou via Internet, si l'on peut configurer
routeurs et parefeux)
- mailslot (peut fonctionner entre plusieurs processus d'un poste,
mais aussi en réseau local)
- messages inter-fenêtres (surtout WM_COPYDATA ; pour certaines
applications qui gèrent cela).
Plus quelques autres moyens particuliers, propres à certaines applications.

Tout cela fonctionne bien sous Windows. Comme tu n'as pas précisé, j'ai
pris la liberté de choisir.
Cependant, quelques-unes devraient fonctionner sous linux, Mac, ou
Windows et ces OS.
Dernières possibilités, qui me semblent intéressantes :
- voir Pyro ;
- voir XMLRPC
(les deux fonctionnent localement et en réseau).

Le choix devra aussi tenir compte de la vitesse souhaitée. Par exemple,
avec COM, je dépasse allègrement les 10000 appels par seconde. Mais,
avec TCP/IP, difficile de faire mieux que 50 à 100 /s (en réseau local).


@-salutations



Merci pour cette réponse.

Je travaille en ce moment à une « arène » pour « robots » dans l'idée
générale du jeu Real Time Battle mais en tour par tour. Pour que les «
robots » puissent être programmés dans n'importe quel langage j'avais
envisagé de les faire communiquer via les entrées sorties standards
comme dans Real Time Battle. Il semble en effet que l'aspect tour par
tout m'empèche de faire de la sorte. Je vais regarder à utiliser un
autre moyen de faire communiquer les « robots » avec leur environnement.

Je souhaite que mon code soit portable ce qui exclu COM et mailslot.
Comme j'aimerais que les robots puissent être dans n'importe quel
langage pyro est exclu également. Je vais regardé du côté des socket et
de xmlrpc. Sans doute d'avantage les socket qui me semblent utilisable
dans plus de langages de programmation.

Jonathan Barnoud
Avatar
Olivier Ravard
Méta-MCI (MVP) a écrit :
Bonsoir !

Pour faire de l'IPC (Inter-Processus-Communication), j'utilise les
voies suivantes :
- COM, si un des processus est serveur COM accessible par l'autre
- COM, via un serveur COM commun et persistant (j'ai créé PBridge
pour cela).
- mmap, avec partage d'une zone mémoire de type fichier
- TCP/IP, avec éventuellement un mini-serveur relais (avantage, ça
fonctionne aussi en réseau, ou via Internet, si l'on peut configurer
routeurs et parefeux)
- mailslot (peut fonctionner entre plusieurs processus d'un poste,
mais aussi en réseau local)
- messages inter-fenêtres (surtout WM_COPYDATA ; pour certaines
applications qui gèrent cela).
Plus quelques autres moyens particuliers, propres à certaines applications.

Tout cela fonctionne bien sous Windows. Comme tu n'as pas précisé, j'ai
pris la liberté de choisir.
Cependant, quelques-unes devraient fonctionner sous linux, Mac, ou
Windows et ces OS.
Dernières possibilités, qui me semblent intéressantes :
- voir Pyro ;
- voir XMLRPC
(les deux fonctionnent localement et en réseau).


Si on veut faire communiquer des processus indépendamment de l'OS et sans
exigences particulières sur le débit d'informations transmises, les deux solutions
sont très bien.

En revanche, si on souhaite un débit important entre client / serveur (comme
c'est le cas pour moi car je distribue des calculs sur différents coeurs et
les informations à partager sont de gros volumes de données de type vecteurs
à plusieurs millions (32) d'éléments) je ne pense pas que ça soit la solution idéale.
J'ai développé ma propre solution RPC et "remote object" plus efficace que ces
deux solutions mais je suis tout de même très limité en débit car c'est le TCP/IP
qui est utilisé.

Il y a d'autres solutions implémentées dans le module "processing" ou "pyprocessing".
Ce module a l'air d'être très efficace et il utilise les pipes entre process.
Par contre, je n'ai pas réussi à comprendre le code a propos de l'implémentation
de ces pipes car il utilise des fonctions non documentées ...
Si quelqu'un arrive à comprendre qq chose dans ce module, je suis preneur.

Le choix devra aussi tenir compte de la vitesse souhaitée. Par exemple,
avec COM, je dépasse allègrement les 10000 appels par seconde. Mais,
avec TCP/IP, difficile de faire mieux que 50 à 100 /s (en réseau local).


A ce propos, quel est le débit qu'on peut atteindre entre un client et un serveur COM ?
Est-ce supérieur au TCP/IP ? Dans mon cas le nombre de requêtes est relativement faible.


@-salutations


Avatar
Méta-MCI \(MVP\)
Salut !

À propos des pipes, je me suis toujours posé la question de la taille
maximale des blocs de données pouvant être transmis.
Je sais que, sous windows-2000, c'était 8 ko, mais, ensuite, je n'ai pas
suivi.

@-salutations
--
Michel Claveau
Avatar
Pierre Maurette
Méta-MCI (MVP), le 19/01/2009 a écrit :
Salut !

À propos des pipes,



Hum ...

je me suis toujours posé la question de la taille maximale



Aïe aïe aïe ...

des blocs de données pouvant être transmis.



Ouf !

--
Pierre Maurette
Avatar
Méta-MCI \(MVP\)
> Hum ...
Aïe aïe aïe ...
Ouf !



Mon cher, je me demande si nous avons les mêmes valeurs pour le mot
"Python"...
Avatar
Pierre Maurette
Méta-MCI (MVP), le 21/01/2009 a écrit :
Hum ...
Aïe aïe aïe ...
Ouf !



Mon cher, je me demande si nous avons les mêmes valeurs pour le mot
"Python"...



Aïe aïe aïe ...

--
Pierre Maurette