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

dark poulpo a écrit :

> >> - 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
Tu ne peux absolument rien prouver sans tests....

> >> - 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.

Réfléchis à l'architecture nécessaire : de toute façon, tu sauras
obligé d'avoir un thread d'attente côté serveur *quoique tu fasses*.
(indice : Avec les messages Windows, c'est le thread GUI avec sa pompe
à message qui sert de thread serveur bloquant)

> >> - 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?

C'est la méthode la plus rapide pour transmettre des données d'un
processus à l'autre en Win32. A toi de faire le protocole adapté par
dessus.

mais est ce qu ca veut dire pour autant
quelle est suffisement rapide pour etre integrer dans une boucle

d'affichage

?

Arrêtes de te faire des noeuds au cerveau sur les performances avant
d'avoir fais quelques tests : ca ne sert *strictement* à rien!
La seule chose sur laquelle tu peux travailler à ce niveau pour
optimiser les perfs, c'est de minimiser les quantités de données
échangées (n'envoyer que les différences enter 2 frames, compresser
les données, etc...)

>
> 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.

X Window fonctionne avec une liaison socket, aussi bien en distant
qu'en local...

Arnaud

> 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

Je ne te conseille pas spécialement les mmap comme solution. Arnaud et
Patrick t'ont donné des très bonnes réponses.

AMHA tu compliques trop le problème à cause de tes a priori sur les
performances. Dans un premier temps, fais au plus simple - choisis
quand-même une technologie raisonnable.

Je ne sais pas si ça s'applique à ton cas, mais ça peut simplifier
les choses d'inverser le sens des communications. Par exemple si tu
avais un processus d'affichage qui fait des requêtes de calcul sur un
autre pour ensuite afficher les résultats, c'est peut-être plus
intéressant d'avoir le processus de calcul faire des requêtes
d'affichage.

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?

Chaque processus à un espace mémoire distinct. La première solution
c'est de copier les objets de l'un à l'autre quand tu en as besoin.
C'est lent, mais au moins il n'y a pas de problème d'accès
concurrentiel.

Si tu veux garder de bonnes performances, il faudra que tu partages des
espaces mémoire (pour éviter les copies) et là c'est pas beaucoup
plus compliqué que la synchronisation inter-thread.

Fais attention au fait que dans les listes chaînées il y a des
pointeurs qui sont non portables d'un processus à l'autre.

--
Cyrille Szymanski

> 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)

Ne pas créer de fenêtre n'empêche pas d'avoir une message queue. Il suffit
de faire un appel à une fonction user ou gdi pour en créer une. Donc dès que
y'a un GetMessage dans ton thread ce dernier dispose de sa file de messages.
Rien ne t'empêche de lui envoyer WM_QUIT via PostThreadMessage.

--
Aurélien REGAT-BARREL

Bonjour.

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

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 ... )

Ouille quelle horreur !
Petit mélange de technologies selon moi, voir plus bas...

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.

Ce que je veux dire, c'est qu'en inter-process (mais ça se simule en
inter-thread),
- si vous disposez d'une zone d'échange (unique) pour le serveur, dont
l'entrée est bloquée par un mutex,
- si vos process (ou threads) clients sont capables d'attendre d'avoir le
mutex pour faire une requête à travers cette zone,
- et enfin **si votre serveur écluse assez vite**,
=> alors vous n'avez tout simplement **plus besoin de queue de messages** :
vos clients vont simplement accepter d'être statistiquement bloqués quelques
millisecondes avant exécution d'une requête.

Essayez donc comme ça (en plus du mutex, il vous faut 2 events auto-reset
pour synchroniser le dépôt de la requête puis l'attente du résultat par le
client dans la zone d'échange).

Cordialement,

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

dark poulpo wrote:

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?

Bien entendu, tu ne peux pas passer directement de pointeurs dans un mmap,
car ils n'ont aucun sens dans l'espace d'addressage du processus client.
Une solution, c'est d'utiliser des pointeurs relatifs, càd des pointeurs
dont la valeur est basée non pas sur l'adresse absolue de l'objet pointé,
mais sur l'offset de l'objet pointé par rapport à l'addresse où le mmap est
mappé dans ton processus serveur. Inutile de dire que c'est assez le b****l
à utiliser, mais c'est faisable.

Arnaud

> Bien entendu, tu ne peux pas passer directement de pointeurs dans un mmap,
car ils n'ont aucun sens dans l'espace d'addressage du processus client.
Une solution, c'est d'utiliser des pointeurs relatifs, càd des pointeurs
dont la valeur est basée non pas sur l'adresse absolue de l'objet pointé,
mais sur l'offset de l'objet pointé par rapport à l'addresse où le mmap

est

mappé dans ton processus serveur. Inutile de dire que c'est assez le

b****l

à utiliser, mais c'est faisable.

oué sans compter les allocations et reallocations, je prefere me taper un
tableau tout pourri en guise de compensation.

>Je ne sais pas si ça s'applique à ton cas, mais ça peut simplifier

les choses d'inverser le sens des communications. Par exemple si tu
avais un processus d'affichage qui fait des requêtes de calcul sur un
autre pour ensuite afficher les résultats, c'est peut-être plus
intéressant d'avoir le processus de calcul faire des requêtes
d'affichage.

oué le pb a l'envers c pas idiot, au moins je sais le nom du processus
serveur, ce qui est plus dur dans l'autre sens

>
Ce que je veux dire, c'est qu'en inter-process (mais ça se simule en
inter-thread),
- si vous disposez d'une zone d'échange (unique) pour le serveur, dont
l'entrée est bloquée par un mutex,
- si vos process (ou threads) clients sont capables d'attendre d'avoir le
mutex pour faire une requête à travers cette zone,
- et enfin **si votre serveur écluse assez vite**,
=> alors vous n'avez tout simplement **plus besoin de queue de messages**

:

vos clients vont simplement accepter d'être statistiquement bloqués

quelques

millisecondes avant exécution d'une requête.

Essayez donc comme ça (en plus du mutex, il vous faut 2 events auto-reset
pour synchroniser le dépôt de la requête puis l'attente du résultat par le
client dans la zone d'échange).

oué mais si ya un ralentissement du systeme (par exemple un process qui me
bouffe tout le cpu, ou des accés disque, ...) je vais perdre des messages

Avoir une queue de message meme si elle est vide 90% du temps ne fait pas de
mal et cest rigolo a gerer en tableau.

oué un postthreadmessage, mais pour un processus, t'es fris si ya pas de
fenetre


jai une question, microsoft n'avait pas lacher des sources d'un ancien
windows ya quelque temps?

jaimerai bien avoir la source de gdi32.dll par curiosité

Bonjour,

dark poulpo wrote:

oué un postthreadmessage, mais pour un processus, t'es fris si ya pas
de fenetre

Pourquoi ??? J'ai plein de thread qui envoi des messages a d'autres threads
qui n'ont et n'auront jamais de fenetre...

Doms.