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.
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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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
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).
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
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
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.
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
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
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.
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
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
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.
À 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
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
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