Comment fait windows pour appeler avec sendmessage() la routine d'un autre process sans planter?

dark poulpo wrote:

salut,

tout d'un coup me vient une question,

Comment fait windows pour appeler avec sendmessage() la routine d'un
autre process sans planter a cause de la memoire proteger?

En utilisant un mécanisme IPC où un autre entre les 2 processus... Le
détaildu mécanisme du système de messages Windows n'est pas documenté, par
conte les différentes techniques IPC disponibles le sont.

parceque j'aurais besoin de realiser le meme genre de chose, executer
une routine static (dun autre process) declarée a mon prog a lavance,
en comptant la contrainte du temps reel.

C'est quoi la "contrainte temps réel" exactement?

Dans le désordre, on peu utiliser :
- RPC
- COM
- les sockets.
- les pipes (nommés ou pas).
- les memory mapped files.
- une section shared dans une DLL.
- WriteProcessMemory + CreateRemoteThread (pas la méthode la plus
recommandée, mais bon...)
- les User APC
- les messages Windows (!)
- sans doute d'autres que j'oublie...

Arnaud
MVP - VC

>C'est quoi la "contrainte temps réel" exactement?

un affichage ou la vitesse compte (la 3d quoi)

Dans le désordre, on peu utiliser :
- RPC

vé me documenter

- COM

trop lent

- les sockets.

pas adapté

- les pipes (nommés ou pas).

pas bon

- les memory mapped files.

jai peur que ce soit trop lent

- une section shared dans une DLL.

deja essayé ya longtemps ca navait pas lair de marcher

- WriteProcessMemory + CreateRemoteThread (pas la méthode la plus
recommandée, mais bon...)

beurk

- les User APC

v me renseigner

- les messages Windows (!)

pas bon dans mon cas

- sans doute d'autres que j'oublie...

c'est deja ca, je vais voir

par contre avec tout ca , ya un truc qui me chiffone, ces methodes c bien
pour partager de la memoire pour des donnees, ou dire a un process lambda de
faire une action, mais moi je veux carrement que le process A fasse
lequivalent dun jmp sur la fonction du process X ou lequivalent, mon gros
soucis, est que jai besoin dexecuter une fonction dun processus par le
processus X pour pouvoir synchoniser mon affichage a certain moment.et
pouvoir acceder a la memoire video de lapplication serveur (voir mon pb sur
WM_SYNCPAINT, pour mieux comprendre)

merci

dark poulpo wrote:

C'est quoi la "contrainte temps réel" exactement?

un affichage ou la vitesse compte (la 3d quoi)

Dans le désordre, on peu utiliser :
- RPC

vé me documenter

- COM

trop lent

Tu as testé?

- les sockets.

pas adapté

Pourquoi?

- les pipes (nommés ou pas).

pas bon

Ah?

- les memory mapped files.

jai peur que ce soit trop lent

Dans ce cas t'es mal barré, parce que c'est la méthode la plus rapide
disponible....

par contre avec tout ca , ya un truc qui me chiffone, ces methodes c
bien pour partager de la memoire pour des donnees, ou dire a un
process lambda de faire une action, mais moi je veux carrement que le
process A fasse lequivalent dun jmp sur la fonction du process X ou
lequivalent,

C'est impossible, justement à cause de la mémoire partagée. D'une manière ou
d'une autre, il faut "marshaller" les paramètres et la valeur de retour de
la fonction de ton client vers ton serveur.

mon gros soucis, est que jai besoin dexecuter une
fonction dun processus par le processus X pour pouvoir synchoniser
mon affichage a certain moment.et pouvoir acceder a la memoire video
de lapplication serveur (voir mon pb sur WM_SYNCPAINT, pour mieux
comprendre)

Tu as regardé les sources de VNC? Ca marche très bien avec une liaison
socket...

Arnaud
MVP - VC

Bonjour.

Je réponds à dark poulpo <qsdqd@sss.ss> qui a écrit :

tout d'un coup me vient une question,

Comment fait windows pour appeler avec sendmessage() la routine d'un
autre process sans planter a cause de la memoire proteger?

(J'ai visité votre site et donc apparemment vous êtes assez bon en codage
pour comprendre la suite)

Il fait du RPC et il déguise ça en SendMessage par nostalgie des débuts.
Depuis le mode protégé (c'était en 1994 avec le 386 je crois), un pointeur
quelconque d'un process ne peut plus être utilisé par un autre process :
c'est pas seulement une question d'autorisation, il n'a tout simplement plus
de signification dans un autre process.

Alors bien sûr vous pouvez passer des messages sans pointeur en paramètre
(donc uniquement des entiers ou des données mappables sur un entier 32bits),
mais en général on ne va pas loin ainsi.

parceque j'aurais besoin de realiser le meme genre de chose, executer
une routine static (dun autre process) declarée a mon prog a lavance,
en comptant la contrainte du temps reel.

Donc si vous voulez lancer une routine d'un process (avec des arguments a
priori) et bien sûr attendre la fin pour le timing et éventuellement
récupérer un résultat, vous devez faire dudit process un serveur qui exécute
une requête, et donc vous avez trois problèmes liés :
- envoi de "signal" de commande inter-process (après avoir localisé la
cible),
- synchronisation des deux processes (avec attente à l'entrée et après
requête),
- transfert de données par copie.

Vous devez aussi vous demander si le serveur sera toujours invoqué en local,
ou s'il peut l'être à travers le réseau, parce que dans le second cas il est
évident que cela introduit une problématique de transfert (relativement)
lent et faillible des données, avec une inévitable sérialisation. Pourtant,
c'est de plus en plus inévitable (surtout dans votre contexte de frontal
3D).

Solution :
* soit vous laissez le système faire ce boulot en utilisant le mécanisme
standard (DCOM) qui a l'avantage d'exister, d'être standard et assez bien
optimisé, mais qui va vous imposer une manière de procéder, et vous aurez
l'illusion de l'invocation directe de votre routine même à travers le
réseau,
* soit vous voulez optimiser selon vos critères et vous prenez les choses en
main, sachant qu'il va vous falloir reconstruire les fonctionnalités de
prise de contact, de synchro, et d'échange de données (avec sérialisation et
désérialisation si ça doit passer par le réseau).

Pour les contacts et synchros, le système propose des mutexes, signaux,
events et autre objets nommés, à vous de définir votre protocole.

Pour l'échange, c'est là que vous voyez clairement que la mémoire partagée
est la technique la plus rapide parce que les données sont copiées "à plat"
et donc sans sérialisation. En contrepartie, il y a bien sûr de la gestion
de mémoire à prévoir. Si la cible est distante, il faut rajouter la
sérialisation et la communication réseau (en tenant compte des contraintes
de comptes et des firewalls bien sûr).

question bete, mais je le vois pas se greffer a chaque process, ca
ferait tache :-p

Ca ne se fera pas tout seul ! Soit vous linkez la librairie DCOM, soit vous
linkez la vôtre.

Il est évident que la complexité revient au serveur, qui doit gérer tout
l'arbitrage et donc qui sera propriétaire de la plupart des objets. Donc
pour les process clients, il y aura normalement un simple objet "antenne" à
créer, qui sera caché dans une DLL standard (ou une lib statique, c'est pas
bien gros).

Je l'ai déjà fait (et justement je suis en train de le refaire), je vous
préviens donc : c'est parfaitement abordable, mais ça ne se "bricole" pas.
Il faut bien comprendre ce que font les mécanismes mis en jeu, sinon vous
allez droit au plantage froid (celui où on reboote avec le bouton "reset").

Bon courage :-D

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

On 2005-05-06, dark poulpo <qsdqd@sss.ss> wrote:

C'est quoi la "contrainte temps réel" exactement?

un affichage ou la vitesse compte (la 3d quoi)

Les deux processus ne peuvent pas partager grand chose car ils s'exécutent dans
des espaces d'adressage séparés. Donc il y aura obligatoirement un surcoût par
rapport à un appel direct. Mais si ça se trouve il est négligeable.

Alors le mieux c'est d'aller au plus simple dans un premier temps, et
d'optimiser si ça ne donne pas de bons résultats ensuite. Comme on dit,
*Premature optimization is the root of all evil*.

- RPC

vé me documenter

- COM

trop lent

Ce sont deux méthodes qui valent le coup d'essayer. Elles ont l'avantage d'être
simples, documentées, et d'être orientées "invocation".

- les sockets.

pas adapté

- les pipes (nommés ou pas).

pas bon

Ça reste de loin le plus simple à mettre en place AMHA. Je ne vois pas de
raison de les rejeter.

- les memory mapped files.

jai peur que ce soit trop lent

- les messages Windows (!)

pas bon dans mon cas

Non, les mmap c'est très rapide par contre c'est un peu la galère à gérer.
Explique pourquoi tu rejettes toutes ces méthodes si tu veux de meilleurs
conseils.

- sans doute d'autres que j'oublie...

c'est deja ca, je vais voir

Il y a pas mal d'objets globaux qui font de l'IPC, genre tous les objets
de synchronisation comme les mutex, semaphores, events...

--
Cyrille Szymanski

> >> - COM
> trop lent
Tu as testé?

non mais quand je vois les coinstance et autre bordel , ca fait des couches
en trop, et des couches en trops * plein de boucles = trop de temps perdu

>> - les sockets.
> pas adapté
Pourquoi?

comme les pipes , ca mobliges a avoir soit un thread a coté, soit ca va me
bloquer l'api juste pour recuperer ou envoyer des donnees, ca ne me va pas.

>> - les memory mapped files.
> jai peur que ce soit trop lent
Dans ce cas t'es mal barré, parce que c'est la méthode la plus rapide
disponible....

plus rapide parmis les autres? mais est ce qu ca veut dire pour autant
quelle est suffisement rapide pour etre integrer dans une boucle d'affichage
?

Tu as regardé les sources de VNC? Ca marche très bien avec une liaison
socket...

non jai pas vu, mais eux se permettent davoir un petit temps de transfert
entre le client et le serveur, moi le serveur tourne sur le meme ordi. kan
je parle de serveur, c plus a voir comme un X window.

> Les deux processus ne peuvent pas partager grand chose car ils s'exécutent

dans

des espaces d'adressage séparés. Donc il y aura obligatoirement un surcoût

par

rapport à un appel direct. Mais si ça se trouve il est négligeable.
Alors le mieux c'est d'aller au plus simple dans un premier temps, et
d'optimiser si ça ne donne pas de bons résultats ensuite. Comme on dit,
*Premature optimization is the root of all evil*.

>> - RPC
> vé me documenter
>> - COM
> trop lent

Ce sont deux méthodes qui valent le coup d'essayer. Elles ont l'avantage

d'être

simples, documentées, et d'être orientées "invocation".

oué faut que je trouve de la doc sur RPC qui soit bien documenté, (si
possible pas sur msdn parceque ya certain mots que defois je comprend pas ,
d'ou une mauvaise traduction)

>> - les sockets.
> pas adapté
>> - les pipes (nommés ou pas).
> pas bon

Ça reste de loin le plus simple à mettre en place AMHA. Je ne vois pas de
raison de les rejeter.

>> - les memory mapped files.
> jai peur que ce soit trop lent
>> - les messages Windows (!)
> pas bon dans mon cas

Non, les mmap c'est très rapide par contre c'est un peu la galère à gérer.
Explique pourquoi tu rejettes toutes ces méthodes si tu veux de meilleurs
conseils.

voir ma response du post juste au dessus

en plus c vrai que les mmap ont besoin d'un nom, c pas genial quand tu dois
faire du dynamique et en creer plusieurs

dailleur jen profite pour poser une question, c'est pas un peu trop le
bordel quand on veut pouvoir faire des listes chainées en memoire partagé
entre processus?


jai du faire une dll ce week end avec n section partagé qui devait
normalement avoir une liste chainée (deja les std::<????> c'est meme pas la
peine), du coup j'ai du creer un tableau dune longueur max pour compenser
l'effet liste chainé. c'est pas terrible.

merci,

je viens d'apprendre par un pote que linux passe par les IPC pour la com, ca
me donnera un element de plus pour m'aider a me decider.

Pour ce qui est des messages, jai deja commencé des testes de mes propres
queues de messages mais juste inter thread donc pas encore de memoire
partagé, parceque je n'ouvre pas de fenetre windows (donc aucune queue de
créees dapres microsoft, ce qui est debile parceque WM_QUIT n'est pas
vraiment lié a une fenetre)

enfin bref, jai un milliard de chose a voir. jy retourne.

Bonjour.

Je réponds à dark poulpo <qsdqd@sss.ss> qui a écrit :

merci,

je viens d'apprendre par un pote que linux passe par les IPC pour la
com, ca me donnera un element de plus pour m'aider a me decider.

Vous savez, que ça s'appelle Remote Procedure Call, Inter Process Call ou
similaire, la problématique est la même, c'est celle que je vous ai décrite
par le menu...
Donc soit vous adoptez une technologie existante, avec ses avantages et ses
inconvénients, soit vous créez la vôtre à partir d'éléments de base, qui
soient portables sur les plates-formes envisagées si ça fait partie de vos
objectifs.

C'est l'éternel problème du choix entre prêt à porter et sur mesure, le coût
se mesurant en cachets d'aspirine.

Pour ce qui est des messages, jai deja commencé des testes de mes
propres queues de messages mais juste inter thread donc pas encore de
memoire partagé, parceque je n'ouvre pas de fenetre windows (donc
aucune queue de créees dapres microsoft, ce qui est debile parceque
WM_QUIT n'est pas vraiment lié a une fenetre)

Ca s'appelle Windows et la structure de programmation date d'une époque où
il y avait forcément une fenêtre. Même les services NT traitent les messages
et attendent le WM_QUIT.

En inter-thread vous faites ce que vous voulez parce que la mémoire est déjà
partagée. Mais ça peut vous permettre de valider un mécanisme de synchro que
vous allez ensuite transposer en inter-process.
Par contre je vous suggère d'abandonner la queue de messages pour ça parce
qu'elle introduit une facilité d'attente à laquelle vous devrez renoncer par
la suite. Voyez plutôt WaitForSingleObject(), CreateMutex() et
CreateEvent()... Avec ça vous avez tout mais je ne vais pas vous le coder,
ça vous gâcherait tout le plaisir ;-)

enfin bref, jai un milliard de chose a voir. jy retourne.

Anglicisme pervers ? Même pas... C'est 101 en Anglais, qui se traduit par 36
en Français il me semble :o)

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

> Par contre je vous suggère d'abandonner la queue de messages pour ça parce
qu'elle introduit une facilité d'attente à laquelle vous devrez renoncer

par

la suite. Voyez plutôt WaitForSingleObject(), CreateMutex() et
CreateEvent()... Avec ça vous avez tout mais je ne vais pas vous le coder,
ça vous gâcherait tout le plaisir ;-)

deja utilisé, ds le postmessage() je waitfor...() je rajoute mon nouvo
message, je setevent() et je release() mon waitfor(), et le getmessage()
fait waitfor(), regarde si ya un message (par la taille) si c le cas il
release() et retourne une valeur en fonction (equivalent de WM_QUIT, ou
pas), sinon il release() et attend le setevent() du postmessage(), quand il
arrive il revient au debut (regarde si ya un message ... )


un de mes problemes, qui va etre aussi penible (comme jai deja cité) ca va
etre l'utilisation des listes chainées en memoire partagé. du coup j'aui du
compenser en creant un tableau d'un taille fixe (ex: 1000 cellules) en
bloquant tout nouveau message si on va depasser la taille.
chose que jai deja du faire pour lister les processus se declarant au
serveur X. C'est peut etre ceux a quoi vous vouliez en venir en parlant
d'abandonner la queue de message.