Comment fait windows pour appeler avec sendmessage() la routine d'un autre process sans planter?
26 réponses
dark poulpo
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?
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.
question bete, mais je le vois pas se greffer a chaque process, ca ferait
tache :-p
> oué un postthreadmessage, mais pour un processus, t'es fris si ya pas de fenetre
Pourquoi ? Je viens de t'expliquer le contraire.
jai une question, microsoft n'avait pas lacher des sources d'un ancien windows ya quelque temps?
Pas à ma connaissance. Il y a eu une fuite des sources de Win2K, par la faute de Mainsoft (US, pas france ;-) je crois.
jaimerai bien avoir la source de gdi32.dll par curiosité
Dans ces cas là, je me rabat sur les sources de ReactOS.
-- Aurélien REGAT-BARREL
Patrick 'Zener' Brunet
Bonjour.
Je réponds à dark poulpo qui a écrit :
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
Quand vous faites du multi-thread ou multi-process, c'est à vous de concevoir la chronologie pour qu'une intervention humaine ou autre ne ralentisse pas les process critiques. Il est bien entendu hors de question de mettre des fonctions IHM là dedans - et pourquoi pas une MessageBox aussi :-D Si votre serveur n'arrive pas à suivre en temps réel, alors vous avez un problème de fond : c'est lui qui va devoir gérer une queue de requêtes, mais alors il faut garantir qu'il arrive globalement à la résorber, et par ailleurs ça implique que les clients vont devoir se contenter d'une promesse d'exécution.
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.
Ah, si c'est pour le côté rigolo, je n'ai plus rien à dire... :o)
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
Je réponds à dark poulpo <qsdqd@sss.ss> qui a écrit :
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
Quand vous faites du multi-thread ou multi-process, c'est à vous de
concevoir la chronologie pour qu'une intervention humaine ou autre ne
ralentisse pas les process critiques. Il est bien entendu hors de question
de mettre des fonctions IHM là dedans - et pourquoi pas une MessageBox aussi
:-D
Si votre serveur n'arrive pas à suivre en temps réel, alors vous avez un
problème de fond : c'est lui qui va devoir gérer une queue de requêtes, mais
alors il faut garantir qu'il arrive globalement à la résorber, et par
ailleurs ça implique que les clients vont devoir se contenter d'une promesse
d'exécution.
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.
Ah, si c'est pour le côté rigolo, je n'ai plus rien à dire... :o)
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
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
Quand vous faites du multi-thread ou multi-process, c'est à vous de concevoir la chronologie pour qu'une intervention humaine ou autre ne ralentisse pas les process critiques. Il est bien entendu hors de question de mettre des fonctions IHM là dedans - et pourquoi pas une MessageBox aussi :-D Si votre serveur n'arrive pas à suivre en temps réel, alors vous avez un problème de fond : c'est lui qui va devoir gérer une queue de requêtes, mais alors il faut garantir qu'il arrive globalement à la résorber, et par ailleurs ça implique que les clients vont devoir se contenter d'une promesse d'exécution.
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.
Ah, si c'est pour le côté rigolo, je n'ai plus rien à dire... :o)
Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Vincent Burel
"dark poulpo" wrote in message news:427b1684$0$1236$
salut, Comment fait windows pour appeler avec sendmessage() la routine d'un autre process sans planter a cause de la memoire proteger?
ben, encore heureux que le système d'exploitation puisse communiqeur avec toutes les appli en cours...
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.
En communication , qui plus est temps-réel, il y a quantité de méthodes parce que il y a une quantité de contraintes possible. J'ai d'ailleurs récemment fait une étude sur les méthodologie de communication entre thread (virtuel ou physique) en fonction des contraintes du temps réel...
Bref, dans tous les cas, communiquer implique la mise en place d'un pipe et d'un protocole. Autrement dit il vous faut une interface logiciel qui permet d'envoyer des données (une sorte de "sendMessage", ou un PushData) et il vous faut définir un protocol de communication, c'est à dire une organisation et une structure de donnée vous permettant de communiquer ce que vous voulez.
Mettre en place un processus de communication, peut devenir très vite complexe. Mais, dans votre cas , une communication unidirectionnel simple peut suffir. Ensuite il faut déterminer les contrainte de la communication et se poser divers questions : par exemple :
Emmetteur : -1- débit, combien de fois par seconde il peut y avoir émission, et combien de données cela représente par seconde.
Récepteur : -2- débit, combien de fois par seconde le recepteur peut être appelé par seconde au maximumet combien de donnée peuvent être traité.
-3- Dans quel mesure les données sont dépendantes du temps ? -4- Est-ce que l'émétteur peut subir des cycle d'attente dans le cas ou le récepteur ne serait pas prêt à recevoir les donnée (on peut se poser la même question pour le récepteur).
Bref, en fonction de toute les contraintes, on pourra mettre en oeuvre différente stratégie de communication. Pour la forme, et pour être totalement libre, je vous conseille par exemple de faire une DLL avec de la memoire partagée privée ou mappé. Ainsi vous pourrez mettre en oeuvre vos outil de communication comme bon vous semble.
VB
"dark poulpo" <qsdqd@sss.ss> wrote in message
news:427b1684$0$1236$8fcfb975@news.wanadoo.fr...
salut,
Comment fait windows pour appeler avec sendmessage() la routine d'un autre
process sans planter a cause de la memoire proteger?
ben, encore heureux que le système d'exploitation puisse communiqeur avec
toutes les appli en cours...
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.
En communication , qui plus est temps-réel, il y a quantité de méthodes
parce que il y a une quantité de contraintes possible. J'ai d'ailleurs
récemment fait une étude sur les méthodologie de communication entre thread
(virtuel ou physique) en fonction des contraintes du temps réel...
Bref, dans tous les cas, communiquer implique la mise en place d'un pipe et
d'un protocole. Autrement dit il vous faut une interface logiciel qui permet
d'envoyer des données (une sorte de "sendMessage", ou un PushData) et il
vous faut définir un protocol de communication, c'est à dire une
organisation et une structure de donnée vous permettant de communiquer ce
que vous voulez.
Mettre en place un processus de communication, peut devenir très vite
complexe. Mais, dans votre cas , une communication unidirectionnel simple
peut suffir. Ensuite il faut déterminer les contrainte de la communication
et se poser divers questions : par exemple :
Emmetteur :
-1- débit, combien de fois par seconde il peut y avoir émission, et combien
de données cela représente par seconde.
Récepteur :
-2- débit, combien de fois par seconde le recepteur peut être appelé par
seconde au maximumet combien de donnée peuvent être traité.
-3- Dans quel mesure les données sont dépendantes du temps ?
-4- Est-ce que l'émétteur peut subir des cycle d'attente dans le cas ou le
récepteur ne serait pas prêt à recevoir les donnée (on peut se poser la même
question pour le récepteur).
Bref, en fonction de toute les contraintes, on pourra mettre en oeuvre
différente stratégie de communication. Pour la forme, et pour être
totalement libre, je vous conseille par exemple de faire une DLL avec de la
memoire partagée privée ou mappé. Ainsi vous pourrez mettre en oeuvre vos
outil de communication comme bon vous semble.
"dark poulpo" wrote in message news:427b1684$0$1236$
salut, Comment fait windows pour appeler avec sendmessage() la routine d'un autre process sans planter a cause de la memoire proteger?
ben, encore heureux que le système d'exploitation puisse communiqeur avec toutes les appli en cours...
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.
En communication , qui plus est temps-réel, il y a quantité de méthodes parce que il y a une quantité de contraintes possible. J'ai d'ailleurs récemment fait une étude sur les méthodologie de communication entre thread (virtuel ou physique) en fonction des contraintes du temps réel...
Bref, dans tous les cas, communiquer implique la mise en place d'un pipe et d'un protocole. Autrement dit il vous faut une interface logiciel qui permet d'envoyer des données (une sorte de "sendMessage", ou un PushData) et il vous faut définir un protocol de communication, c'est à dire une organisation et une structure de donnée vous permettant de communiquer ce que vous voulez.
Mettre en place un processus de communication, peut devenir très vite complexe. Mais, dans votre cas , une communication unidirectionnel simple peut suffir. Ensuite il faut déterminer les contrainte de la communication et se poser divers questions : par exemple :
Emmetteur : -1- débit, combien de fois par seconde il peut y avoir émission, et combien de données cela représente par seconde.
Récepteur : -2- débit, combien de fois par seconde le recepteur peut être appelé par seconde au maximumet combien de donnée peuvent être traité.
-3- Dans quel mesure les données sont dépendantes du temps ? -4- Est-ce que l'émétteur peut subir des cycle d'attente dans le cas ou le récepteur ne serait pas prêt à recevoir les donnée (on peut se poser la même question pour le récepteur).
Bref, en fonction de toute les contraintes, on pourra mettre en oeuvre différente stratégie de communication. Pour la forme, et pour être totalement libre, je vous conseille par exemple de faire une DLL avec de la memoire partagée privée ou mappé. Ainsi vous pourrez mettre en oeuvre vos outil de communication comme bon vous semble.
VB
dark poulpo
merci de l'explication, en ce moment, jai pas le temps, je sauve tout et je relirai tout ca
merci de l'explication, en ce moment, jai pas le temps, je sauve tout et je
relirai tout ca
merci, je suis plus trop dans le sujet pour linstant, mais de toute facon je garde tout
dark poulpo
merci pour cette explication et conseil. jai du faire place a quelque priorité avant , du coup c en attente, come aji deja dis, je garde le tout pour my replonger des que possible.
merci pour cette explication et conseil. jai du faire place a quelque
priorité avant , du coup c en attente, come aji deja dis, je garde le tout
pour my replonger des que possible.
merci pour cette explication et conseil. jai du faire place a quelque priorité avant , du coup c en attente, come aji deja dis, je garde le tout pour my replonger des que possible.
