Discussion :

[Médinoc]

Il y a tout plein de mécanismes possibles sous Windows pour communiquer de grosses données sous Windows:
http://msdn.microsoft.com/library/de...unications.asp

J'ai déjà utilisé:

• Tubes anonymes avec DuplicateHandle() (Pipes, local)
• Tubes anonymes hérités par un processus fils (Pipes, local)
• Message WM_COPYDATA (Data Copy, local)
• Mémoire partagée anonyme (File Mapping, local)
• Sockets (Windows sockets, distribuable)

Ainsi, selon les besoins (local ou potentiellement distribué) les choix ne manquent pas...
Mettre en branle DCOM pour une bête copie locale, c'est utiliser un marteau-pilon pour écraser une mouche...

[Jan Rendek]

... mais est-ce qu'on peut alors parler de communication ?
on ne compare pas COM / DBUS et des evenements de synchronisation

... quand meme !

Y'a un truc que je répète 100 fois par an à mes étudiants. Lisez attentivement et complètement le sujet avant de commencer.
Je t'invite à lire attentivement la question posée dans ce fil de discussion.
La solution retenue marche, au problème d'implémentation près. Un événement nommé sous windows permet de synchroniser deux processus.
Je n'ai pas de windows sous la main pour pouvoir débugger le code initial, mais je sais d'expérience que ça marche.

Sans aucun doute, on peut faire des trucs de folies avec DCOM, DBUS et tout le caravansérail. Mais quand on me demande quel outil utiliser pour planter un clou, je préfère conseiller un marteau plutot que la caisse à outils multifonctions électrique à brancher sur secteur, qui de surcroît fait le café.

Pour ce qui est de la terminologie, à partir du moment ou un processus peut influer sur le comportement d'un autre on parle de communication interprocessus. Même s'il s'agit d'un simple événement. Parmis tous les objets inclus dans IPC (InterProcess Communication) , beaucoup ne servent pas à transmettre des données d'un processus à un autre (mutex, sémaphores, etc.).

[epsilon68]

Honnetement moi je prefere toujours demander pourquoi et leur donner une maniere solide de faire que deux processus communiquent ensemble ... simplement et proprement.

le non merci ! que tu as exclamé quelques posts avant m'a fait clairement comprendre que tu ne vois pas au contraire la simplicité de COM. Parce que c'est vraiment simple et autrement plus puissant qu'un message WM_XXX

Par contre j'admets avoir perdu le fil et m'etre ecarté du probleme de l'auteur de ce thread et aussi m'etre égaré de la terminologie exacte, meme si je ne considere pas un event (tres deconseillé) ou un mutex semaphore comme des objets de communication mais de synchronization qui est pour moi tres tres different.

Pour moi un WM_XXX est une bidouille, un workaround. c'est pas evolutif et meme pas fiable ...
Un event ou un mutex c'est de la synchronization et souvent tres dure a debugger ...

... mais chacun est libre d'utiliser ou de conseiller la maniere la plus appropriée pour lui !

[Médinoc]

Note: WM_COPYDATA n'est pas WM_XXX.
Il y a un vrai mécanisme derrière, qui donne au processus destinataire un accès en lecture sur les données en question.
En fait, on pourrait comparer cela à l'envoi d'un paquet UDP.

Ou, à un WM_XXX qui porterait beaucoup plus de données qu'un simple triplet message/WPARAM/LPARAM...

Mais cela reste une communication interprocessus, idéale dans le contexte événementiel de deux programmes fenêtrés. Mais COM n'est pas du tout "tout simple" : J'ai fouillé dans la structure profonde de COM avec les COM Tutorial Samples, et le COM interprocessus est une usine à gaz. (le COM in-process, lui, peut encore être qualifié de simple).


Quant aux events, dans la pratique, ils sont plus souvent utilisés au sein d'un processus que pour communiquer d'un processus à l'autre, mais ils restent utilisables à cette fin.

[epsilon68]

Mais COM n'est pas du tout "tout simple" : J'ai fouillé dans la structure profonde de COM avec les COM Tutorial Samples, et le COM interprocessus est une usine à gaz. (le COM in-process, lui, peut encore être qualifié de simple).

il ya deux ans j'utilisais VB,
et maintenant j'utilise .NET comme wrapper.

... et c'est tres simple.

Il ne faut plus non plus hesiter a changer de technology pour certain bouts de code, sinon on ne s'en sort plus.

... sur Mac je l'encapsulerais en Objective C et sur Linux j'ecrirais un adapter DBUS ou DCOP.

[Jan Rendek]

J'ai suffisamment utilisé COM pour savoir que ce n'est pas simple. Surtout lorsque l'on ne souhaite pas utiliser toute la panoplie, mais juste une fonctionnalité. Préconiser d'utiliser COM plutot qu'un objet de synchronisation simple dans ce cas est une erreur.

Enfin, soyons sérieux deux minutes. La solution qui n'utilise que win32 nécéssite 4 appels de fonctions. Tes solutions à base de COM ou autre nécéssite un nombre conséquent de bibliothèques liées et un langage évolué ou un IDE pour masqué la complexité de COM (rien que voir les en-têtes standard de l'ATL pour donner des boutons).
La synchronisation de deux processus est essentielles dans beaucoup de tâche système, tu crois que le noyeau Linux utilise DBUS uniquement pour faire un 'join' entre 2 tâches ?
Ou que le coeur de windows communique via COM ?

[Médinoc]

Surtout que oui, COM est peut-être simple... Quand tu utilises un langage et une plate-forme qui font tout pour toi (VB est très connu pour faciliter l'utilisation de COM...)

[epsilon68]

Parce que maintenant on s'attaque a de la programmation systeme ??
puis aussi je me demande laquelle solution est la plus facilement portable d'ailleurs...

moi aussi j'ai fait assez de COM pour te dire que c'est simple (et tres pratique), mais effectivement il faut utiliser les bons outils, et Microsoft utilise COM intensement dans ses outils.

Mais bref, comme j'avais dit dans un de mes posts precedents, il est vrai que je me suis egaré par rapport a la question initiale et au probleme posé.

... surement parce que le titre est "communication entre 2 processus" et pas "synchronisation ..."

[Jan Rendek]

moi aussi j'ai fait assez de COM pour te dire que c'est simple (et tres pratique), mais effectivement il faut utiliser les bons outils, et Microsoft utilise COM intensement dans ses outils.

Puisque je ne suis toujours pas de ton avis, je te propose la chose suivante.
Ecrivons un exemple que synchronise 2 processus sous windows. P1 se lance, se met en attente. P2 se lance et libère P1. Le tout sous windows en C++.
Utilise COM, et j'utiliserais win32
Nous verrons quelle est la solution la plus adaptée.

Je m'y attèlerais ce soir dès que j'aurais un windows sous la main.

<remarque>J'éviterais de lancer le débat sur la portabilité de la synchro entre processus ainsi que la portabilité de COM/DCOM</remarque>

[epsilon68]

Puisque je ne suis toujours pas de ton avis, je te propose la chose suivante.
Ecrivons un exemple que synchronise 2 processus sous windows. P1 se lance, se met en attente. P2 se lance et libère P1. Le tout sous windows en C++.
Utilise COM, et j'utiliserais win32
Nous verrons quelle est la solution la plus adaptée

Nous savons tous les deux la reponse dans ce cas ...
effectivement de synchronisation et non de communication.

Je peux te proposer autre chose: faire un moteur de calcul d'usinage et une interface graphique le tout pilotable par un autre processus me renvoyant la progression point par point ?

Je pense qu'on ne parlait pas de la meme chose effectivement...

[Médinoc]

Là, on ne parle plus de communication mais de pilotage.
D'où, nécessité d'un mécanisme de RPC (dont DCOM).

[epsilon68]

tu fais deux exe com et tu peux communiquer dans les deux sens, se mettre en attente etc...

J'aimerais bien voir un grand projet avec des synchronisations partout, ca doit etre marrant a voir ...

[epsilon68]

mais c'est vrai, c'est du RPC dans ce cas...
je suis donc hors-sujet

EDIT en fait non voir en dessous

[epsilon68]

en fait non je ne suis pas hors sujet (de ce thread si mais pas de la communication entre processus)

The following IPC mechanisms are supported by Windows:

* Clipboard
* COM <----------- je suis la
* Data Copy
* DDE
* File Mapping
* Mailslots
* Pipes
* RPC <---------- et la aussi
* Windows Sockets

[Rupella]

Parce que maintenant on s'attaque a de la programmation systeme ??

Bien sûr qu'on s'attaque à la programmation système !!! C'est la base de tout OS !
IPC est l'une des premières choses que j'ai vues pour apprendre la programmation C sous Unix, et dans tout cours système digne de ce nom, tu trouveras ces mécanismes explicités, avant de t'attaquer à de la programmation temps réel...

personnellement, je resterai attaché à l'utilisation des mécanismes IPC qui (je le répète) sont largement éprouvés, voire à l'utilisation des sockets, bien avant de penser à COM, qui comme tu le dis fait intervenir 2 ou 3 langages différents pour avoir un truc classe, lourd, et pas forcément compréhensible par tout le monde et donc, difficile à maintenir... il ne faut surtout pas oublier ce point là !

mais effectivement, on peut choisir d'utiliser un marteau pilon pour casser une noisette, rien que pour le plaisir de se dire qu'on à utilisé le marteau pilon, alors qu'on cherche uniquement à casser une misérable noisette... (paix à son ame).

[epsilon68]

personnellement, je resterai attaché à l'utilisation des mécanismes IPC qui (je le répète) sont largement éprouvés, voire à l'utilisation des sockets, bien avant de penser à COM,

Les sockets au lieu de COM ou DBus... mais bien sur

Je fais tous les jours du COM, et les sockets ne me viendraient meme pas a l'esprit ... sauf bien sur dans quelque ca particulier (1 fois en 7 ans).

et l'exemple des events en C win32 entre processus, ca va pour un exemple scolaire ou de la programation tres specifique (oui un noyau/driver c'est specifique) par contre pour un programme plus gros... vous n'etes vraiment pas serieux !

En plus COM et RPC font partie des mecanismes IPC, du coup je me croyais hors-sujet mais c'est bien vous qui l'etes en refusant d'admettre COM. C'est lourd ? oui mais ca gere beaucoup de cas (d'erreur, de marshalling etc).
Comme dit c'est a chacun de voir midi a sa porte.

[Jan Rendek]

moi je fais tous les jours du COM, et les sockets ne me viendraient meme pas a l'esprit ... sauf bien sur dans quelque ca particulier (1 fois en 7 ans).

et l'exemple des events en C win32 entre processus, ca va pour un exemple scolaire ou de la programation tres specifique (oui un noyau/driver c'est specifique) par contre pour un programme plus gros... vous n'etes vraiment pas serieux !

Je suis très sérieux.
Pour ta gouverne tu n'es pas le seul à avoir un pédigré. Je travaille dans le génie logiciel depuis une dizaine d'années et d'autres sur ce forum sont bien plus expérimentés que moi. Des projets d'envergures j'en ai vu passer quelques-uns, des ingénieurs aussi. Ce qui me gonfle le plus dans la profession c'est justement les ingénieurs qui arrivent avec des solutions toutes faites et des a priori technologiques. C'est typiquement le genre de personnes qui au lieu de choisir une solution et des outils adaptés au problème posé passent leur temps à justifier leurs choix idéologiques.
Ensuite, tu peux faire un census. Je suis convaincu qu'il y a largement plus d'application multiprocessus qui communiquent via un systeme des sockets géré par l'appli qu'en employant une encapsulation par COM/DCOM.
Ces technos ne sont en aucun cas la panacée et possèdent des inconvénients rédhibitoires dans bon nombre de projets.

[epsilon68]

Je suis très sérieux.
Pour ta gouverne tu n'es pas le seul à avoir un pédigré. Je travaille dans le génie logiciel depuis une dizaine d'années et d'autres sur ce forum sont bien plus expérimentés que moi. Des projets d'envergures j'en ai vu passer quelques-uns, des ingénieurs aussi. Ce qui me gonfle le plus dans la profession c'est justement les ingénieurs qui arrivent avec des solutions toutes faites et des a priori technologiques. C'est typiquement le genre de personnes qui au lieu de choisir une solution et des outils adaptés au problème posé passent leur temps à justifier leurs choix idéologiques.

Alors la je suis decu de ce genre de post, je le dis franchement.
Tout d'abord tu me parles de "pedigré" et la je suis étonné. Mon mail n'etait pas tourné de la facon "moi je sais tout" mais de la facon "de mon experience c'est toujours COM". Relis tes pots s'il te plait avant de faire des commentaires de la sorte.

Je suis heureux maintenant d'apprendre que tu es plein d'experience, et que des personnes de mon genre te gonflent. Maintenant s'il te plait retourne le probleme dans l'autre sens, je pense que tu négliges completement des technologies qui sont pourtant maintenant partout. Je n'ai jamais dit que tes choix etaient mauvais, simplement ils ne me paraissent pas adapté et ne m'ont jamais traversé l'esprit dans les projets que j'ai pu faire mon "pedigré", mais bon excuse moi des projets d'envergure t'en as vu.

et si nous n'avions pas le meme domaine d'application ?
ne pourrais-tu pas etre le genre de personne que tu decris ?

Ensuite, tu peux faire un census. Je suis convaincu qu'il y a largement plus d'application multiprocessus qui communiquent via un systeme des sockets géré par l'appli qu'en employant une encapsulation par COM/DCOM.
Ces technos ne sont en aucun cas la panacée et possèdent des inconvénients rédhibitoires dans bon nombre de projets.

sur windows je dirais justement qu'ils utilisent majoritairement COM.
mais je dois me tromper bien sur ...

faire des sockets au lieu de COM sur window, c'est vraiment faire un pas en arriere. COM est fait pour dialoguer avec des applications, d'ailleurs on a vu le BOUM des composants, mais on est en plein BOUM des applications utilisés comme des composants. Office, Photoshop, inDesign, RapidForm (CAO) sont quelques exemples de composant-application qu'on peut controler avec COM.
Utilise les sockets et personne n'utilisera ton appli, fais le avec COM et tu t'ouvres a une majorité d'utilisateurs potentiel soucieux de se coupler avec une autre application pour augmenter leur solution.

... excuse moi mais ta reaction est vraiment decevante

[Jan Rendek]

Mon mail n'etait pas tourné de la facon "moi je sais tout" mais de la facon "de mon experience c'est toujours COM". Relis tes pots s'il te plait avant de faire des commentaires de la sorte.

Les sockets au lieu de COM ou DBus... mais bien sur
Je fais tous les jours du COM, et les sockets ne me viendraient meme pas a l'esprit ... sauf bien sur dans quelque ca particulier (1 fois en 7 ans).
et l'exemple des events en C win32 entre processus, ca va pour un exemple scolaire ou de la programation tres specifique (oui un noyau/driver c'est specifique) par contre pour un programme plus gros... vous n'etes vraiment pas serieux !

[epsilon68]

s'il te plait relis tes posts.