Discussion :

[alavoler]

Bjr,

J'ai un pti problème,

j'ai une application qui se lance sur une machine et qui recoit en argument X ensuite elle fait un traitement..., je dois maintenant en lancant une nouvelle fois cette application lui passer un argument Y....

J'ai envie que ce soit le premier processus qui prenne la main... donc je dois en gros verifier si je suis deja lancé, si OUI, alors je dois lui donner mon argument Y, et quitter...

Je crois que c'est de la communication inter-process ?
Le shared memory serait il une bonne solution ?

Je precise que la communication est sur deux "process" issue d'un meme executable sur une machine locale

si quelqu un a des mots clés... ou des conseils je suis preneur

merci

[ced600]

tu n'es pas clair sur ce que tu veux faire.
Ton process est lancé.
Que veux tu faire ?
l'arrêter et le relancer ?
ou le lancer un second process et arrêté le premier ?

[alavoler]

ced600

arf... désolé de pas etre clair, je vais essayer de reformuler:


- la scene se passe sur une seul machine, avec un meme executable:

J'ai toto.exe (pid:1) qui se lance une premier fois, il fait son traitement, il est tjs actif


J'ai toto.exe (pid:2) qui se lance une deuxieme fois (alors que toto.exe (pid:1) est toujours actif), il voit des le debut que toto.exe est deja present sur la machine, il doit donc lui envoyer un "MESSAGE" et quitter


toto.exe (pid:1) lit le "MESSAGE" et fait son traitement...


Je pense que le shared memory peut etre adapté ? par contre je suis obligé de surveiller avec un timer si son contenu a changé ? ou existe t il une meilleurs solution ?

[ced600]

la shared memory me semble adapté. J'ai en tête des solutions moins propre mais c'est moins propre.

Pour qu'un programme sache que quelque chose a changé, il n'a que deux moyen :
- Il surveille la chose (donc en général un timer derrière).
- Il attend que quelque chose lui dise qu'il y a eu du changement (interception, event, ou message d'un autre processus).

Tu peux toujours essayer de t'amuser avec les interceptions, et aller voir en mémoire ce qu'il se passe lorsque tu reçois une interception. Si je ne me trompe pas, windows utilise PosX pour les interceptions.
Bon courage si tu choisis cela (en Unix, ou Linux, c'est pas très compliqué, mais avec windows qui nous masque un peu tout cela ...)

Un timer qui vérifie toutes les 500 ms me semble suffisant. Enfin cela dépend du temps de réaction que tu dois avoir.

[theMonz31]

salut

j'ai posté hier un bout de code qui permet de faire de la shared memory
(ca doit etre le thread interprocess... ou un truc comme cela, plutot
recent dans la liste )

Tu devrais trouver toutes les réponses à tes questions dans ce thread

The Monz, Toulouse

[alavoler]

Merci à vous deux pour vos précieux conseils !

[alavoler]

salut

j'ai posté hier un bout de code qui permet de faire de la shared memory
(ca doit etre le thread interprocess... ou un truc comme cela, plutot
recent dans la liste )

Tu devrais trouver toutes les réponses à tes questions dans ce thread

The Monz, Toulouse

Hum... il n'y a pas moyen de faire du shared memory juste en utilisant l'API windows ?

je crois que le mec utilise un hook non ?

[alavoler]

si quelqu un vois une alternative au shared memory... je suis preneur


y a pas un system de message en local ?

[theMonz31]

non non

le hook, c'est une technique qui consiste à s'inscrire à une chaine de fonction qui sont appelés par l'OS ou bien à re-router des fonctions de traitements vers les tiennes

La, c'est pas du Hook, mais un Wrapper (un adaptateur qui permet d'utiliser en C# des fonctions C++ ou de l'Api Win32 plus facilement)..

Donc, cela ne me semble pas problématique

Apres, sur l'autre thread, une réponse a donné la liste des éléments disponibles pour faire de la communication inter-process

Je pense qu'il faudrait faire une FAQ ou bien un tutoriel sur l'ensemble des techniques disponibles car la question est récurrente ces derniers jours

The Monz, Toulouse

[Graffito]

Bonjour,

Une possibilité en utilisant les socket IP:

• PidB crée un socket IP client qui essaye de se connecter au socket IP server créé par PidA,
• si la connexion de PidB à PidA réussit, Pid B envoie son message sur la socket et s'arrète,
• si la connexion de PidB à PidA échoue, Pid B crée le socket server, détectera les connections de PidC, PidD,... et pourra lire leurs messages.

Sur la même machine :
- host=127.0.0.1
- port= nnnn (usuellement 0x4000 à 0x4100)

[tomlev]

Autre option, utiliser une MessageQueue... j'ai jamais fait, donc je connais pas les possibilités, mais en regardant la doc ça me semble être une bonne façon de faire...
Ou encore le remoting en utilisant un IpcChannel... (jamais testé non plus)

[ced600]

j'ai posté hier un bout de code qui permet de faire de la shared memory
(ca doit etre le thread interprocess... ou un truc comme cela, plutot
recent dans la liste )

Je fais le lien :
http://www.developpez.net/forums/sho...d.php?t=481974

On y parle déjà, si je me souviens bien, de MessageQueue, et d'autre chose.

Je pense qu'il faudrait faire une FAQ ou bien un tutoriel sur l'ensemble des techniques disponibles car la question est récurrente ces derniers jours

En effet cela serait une bonne idée.

[alavoler]

merci pour vos nombreux commentaires.

Parait il, qu'on peut utiliser un objet de synchronisation avec un thread special, qui correspond bien a ma demande (envoie de données intra processes, sur une meme machine)

si quelqu un a des infos la dessus....

[tomlev]

effectivement, il y a les mutex et les sémaphores, mais je suis pas sûr que ça permette de transmettre des données...

[theMonz31]

C'est meme certains

Mutex, semaphore sont des objets de synchronisations dont l'existence remonte aux temps anciens (unix, ya beh 15 ou 20ans)

La seule utilité de ces deux concepts est de limiter l'acces à des ressources et d'etre un moyen de synchronisation eventuel

The Monz, Toulouse

[ced600]

Les mutex et les semaphores existent pour bloquer et débloquer des threads en fonction de la disponibilité ou de l'existence d'une ou plusieurs ressources communes qu'utilisent ces threads.

Edit : J'avais oublié le mot essentiels

[alavoler]

hum.... question coconne...

quelqu un m'a dit qu'on pouvait le faire à travers des threads

il m'a parlé d'EventWaitHandle... http://msdn2.microsoft.com/fr-fr/lib...le(VS.80).aspx


c'est possible de faire communiquer deux process à travers des threads ??

[ced600]

hum.... question coconne...

quelqu un m'a dit qu'on pouvait le faire à travers des threads

il m'a parlé d'EventWaitHandle... http://msdn2.microsoft.com/fr-fr/lib...le(VS.80).aspx


c'est possible de faire communiquer deux process a travers des threads ??

pas clair.

Tu peux faire communiquer des threads entre eux.
Tu peux lancer des process à partir de thread.
Mais cela reviendra au même problème pour tes deux process, qu'ils soient lancés par des threads ou autrement il faut prévoir un moyen de communiquer entre eux, à moins que tes threads soient les process eux même.

Dans ton cas, lorsque tu veux lancer un autre process toto, plutot que de lancer un process, tu peux demander à ton application de lancer un thread qui ne serait autre que le même programme que le thread principale.
Mais je ne sais pas si c'est plus simple, et de toute façon tu devra prévoir la communication entre tes threads.

[alavoler]

Vous pouvez en fait allez plus loin puisque la classe WaitHandle dérive de la classe MarshalBy-
RefObject. Ainsi un objet de synchronisation peut être partagé entre plusieurs processus de
machines différentes qui communiquent avec la technologie .NET Remoting.

ced600
Ca confirme ce que tu dis, grr.... c'est un probleme chiant, parceque revenir à communiquer à travers un protocol reseau, c'est un peu concon en local je trouve, de plus ca peut poser des problemes de firewall...

ralala...

enfin merci beaucoup, vous etes fortiches ! Ce forum est plutot sympa !