Child Process, c'est quoi ?

**backtothend** · 28/07/2006, 17h20

Salut.

Alors j'aimerais vous poser plusieurs questions :
*à quoi peut servir un child process?
>est ce qu'avec la création d'un child process, on peut executer deux instructions à la fois ? (1 pour le process mère et 1 pour le child process)
>est-ce que le child process peut accéder aux .data du process mère ?
*comment créer un child process ? quels APIs ?

En fait, mon projet requiert deux instances : une qui récupère continuellement des infos sur x et l'autre sur y > et tout ça en même temps. Et ces deux instances doivent pouvoir se communiquer RAPIDEMENT les infos récupérées.
C'est pourquoi je pensais au child process.

J'ai eu beau chercher, (docu sur linux la plupart), je n'ai pas réussi à trouver les infos qu'il me fallait. En plus, je me suis totalement embrouillé avec les infos prises de droite à gauche. Je requiers votre aide. (je ne demande pas qu'on me fasse de tuto, un BON lien me suffirait)
Merci

ps : je travaille avec MASM v9

Déplacé depuis le forum Assembleur par Alcatîz

**Médinoc** · 29/07/2006, 12h05

Alors j'aimerais vous poser plusieurs questions :
*à quoi peut servir un child process?

Sous Windows, un Child Process est généralement utilisé pour faire quelque chose de non-relié (ou très peu) à la tâche courante, ou pour utiliser un exécutable sur lequel on n'a aucun contrôle (par exemple, un utilitaire en ligne de commande qu'on n'a pas créé soi-même).
La plupart des environnements de développement par exemple, exécutent le compilateur en tant que child process.

>est ce qu'avec la création d'un child process, on peut executer deux instructions à la fois ? (1 pour le process mère et 1 pour le child process)

Deux process (child ou non) peuvent s'exécuter "en même temps", mais à moins d'être sur un ordinateur bi-processeur, les instructions ne sont pas réellement exécutées simultanément: Le processeur alterne entre les différents process.

>est-ce que le child process peut accéder aux .data du process mère ?

Non, les process sont supposés entièrement séparer. Toutefois il y a des fonctions offertes par le Kernel pour la "Communication Inter-processus" (IPC), comme des fonctions de mémoire partagée.

*comment créer un child process ? quels APIs ?

Sous Windows, la fonction de l'API Win32 est CreateProcess(). Mais on peut également utiliser ShellExecute[Ex]() qui correspond plutôt aux commandes de l'explorateur Windows, ou bien system() qui crée un Child Process et attend automatiquement qu'il se termine.

Pour ce que tu cherches à faire, je pense que le mieux serait un seul processus, mais multi-thread. En fait, sous Windows, chaque processus est composé d'un ou plusieurs threads, et c'est entre threads que le processeur alterne. Deux threads peuvent donc s'exécuter "en même temps", et tous les threads d'un même processus ont accès à la même mémoire (chacun a sa propre pile, par contre)
Edit: Pour cela, renseigne-toi sur les fonctions CreateThread() de l'API Win32 et _beginthreadex() (avec le ex uniquement) de la C Run-Time Library de Windows. Tu trouveras les renseignements sur le site de MSDN...

**backtothend** · 29/07/2006, 12h29

UN GRAND MERCI pour ta réponse qui a véritablement debroussailler mon esprit.

J'avais déjà regardé du côté des threads. Notement avec le tutorial Iczelion.
Mais quand on créé un thread, il faut attendre qu'on passe la main à windows pour que les threads s'executent et le programme mère ne peut rien faire pendant ce temps-là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
	.IF uMsg==WM_CREATE
		invoke CreateEvent,NULL,FALSE,FALSE,NULL
		mov  hEventStart,eax
		mov  eax,OFFSET ThreadProc
		invoke CreateThread,NULL,NULL,eax,\    ==>On créé le thread
                             NULL,NORMAL_PRIORITY_CLASS,\
                             ADDR ThreadID
		mov  hThread,eax
	.ELSEIF uMsg==WM_DESTROY
		invoke PostQuitMessage,NULL
	.ELSEIF uMsg==WM_COMMAND
		mov eax,wParam
		.if lParam==0
			.if ax==IDM_START_THREAD
				invoke SetEvent,hEventStart     ==>On commence le thread mais le thread ne s'execute pas, il faut attendre le ret qui passe la main à windows. Quand le thread est fini il revient vers le programme. Si on créé plusieurs thread, il faut attendre que tout les threads aient fini pour que windows passe la main au programme. (là je suis pas sur de ce que je dit > ce sont juste des observations)
				invoke EnableMenuItem,hMenu,IDM_START_THREAD,MF_GRAYED
				invoke EnableMenuItem,hMenu,IDM_STOP_THREAD,MF_ENABLED
			.elseif ax==IDM_STOP_THREAD
				mov  EventStop,TRUE
				invoke EnableMenuItem,hMenu,IDM_START_THREAD,MF_ENABLED
				invoke EnableMenuItem,hMenu,IDM_STOP_THREAD,MF_GRAYED
			.else
				invoke DestroyWindow,hWnd
			.endif
		.endif

Si quelqu'un pouvait m'en dire plus sur les thread parce qu'en faite je suis peut-être passé à côté de la solution.
Mercii

**Médinoc** · 29/07/2006, 12h44

Mais quand on créé un thread, il faut attendre qu'on passe la main à windows pour que les threads s'executent et le programme mère ne peut rien faire pendant ce temps-là :

Qui est allé te raconter cela ?

Les threads ont TOUJOURS été concurrents depuis le début de Win32...

Dans ton code, le thread est créé dès la création de la fenêtre et l'exécution de ThreadProc() commence immédiatement (à moins que tu n'aies créé le thread avec le flag CREATE_SUSPENDED)...

Et si tu veux être sûr que le nouveau thread commence tout de suite, tu peux lui donner une priorité légèrement supérieure au thread qui le crée...

PS: Un processus se termine si tous ses threads se terminent ou si main()/WinMain() retourne.
Si tu veux que les autres threads continuent de tourner après la fin du main(), tu dois rajouter un appel à ExitThread() ou _endthreadex() à la fin du main().

PPS: NORMAL_PRIORITY_CLASS n'est pas listé dans l'aide comme une valeur de flags valide.
En plus, cela s'applique aux processus. Pour les threads, on utiliserait plutôt THREAD_PRIORITY_NORMAL.

**backtothend** · 29/07/2006, 13h01

He bien en faite sous debugger quand j'ai passé l'API CreateThread, j'avais beau attendre que le ThreadProc créé le MessageBox il n'apparaissait pas. Quand j'ai passé la main à windows (après le ret) le MessageBox est apparu, j'en ai donc conclu qu'il fallait passé la main à windows pour executer un thread.
Je vais testé tes conseils de suite. Merci encore pour ton aide

))))

**Médinoc** · 29/07/2006, 13h14

Qu'avais-tu mis dans le paramètre hWndParent de ta MessageBox() ?
Il faut savoir que deux threads ont des files de message différentes, mais se retrouvent reliés si leurs fenêtres sont reliées. hWndParent doit donc être NULL.

**backtothend** · 29/07/2006, 13h24

Voilà ce que j'avais mis :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
.code
start:
mov eax, offset ThreadProc1
invoke CreateThread,NULL,NULL, eax, NULL, THREAD_PRIORITY_NORMAL, ADDR ThreadID1
mov eax, offset ThreadProc2
invoke CreateThread,NULL,NULL, eax, NULL, THREAD_PRIORITY_NORMAL, ADDR ThreadID2
ret

ThreadProc1 proc
invoke MessageBox, 0, addr txt1, addr cap1, 0
ret
ThreadProc1 endp

ThreadProc2 proc
invoke MessageBox, 0, addr txt2, addr cap2, 0
ret
ThreadProc2 endp

end start

Jusqu'à l'execution du ret, rien ne se passe. Lorsque je passe le ret les deux MessageBox s'affichent.

**Médinoc** · 29/07/2006, 13h27

Essaie en appelant SetThreadPriority avec une priorité supérieure sur un des threads que tu viens de créer: La commutation n'est pas immédiate, chaque thread dispose d'un quantum de temps avant commutation. Mais avec une différence de priorité, le thread de priorité inférieure peut être interrompu avant la fin de son quantum.

**backtothend** · 29/07/2006, 13h35

QUEL CON JE FAIS.
En faite, et je sais pas pourquoi, quand on debugge l'application qui créé les thread, les thread ne se lancent pas. Par contre quand on lance l'executable (sans debugger), les thread se lancent automatiquement après leur création.

ps : je viens de découvrir une API qui ne se débugge pas ^^

**backtothend** · 29/07/2006, 13h48

En faite je comprend de moins en moins cette API.
Si on execute le programme ci-dessus avec un debugger (step by step), les ThreadProc ne s'executent que lorsqu'on passe la main à windows.
Si on modifie le programme ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
.code
start:
mov eax, offset ThreadProc1
invoke CreateThread,NULL,NULL, eax, NULL, THREAD_PRIORITY_NORMAL, ADDR ThreadID1

invoke MessageBox, 0, addr txt3, addr cap3, 0 ==> rajout

mov eax, offset ThreadProc2
invoke CreateThread,NULL,NULL, eax, NULL, THREAD_PRIORITY_NORMAL, ADDR ThreadID2
ret

ThreadProc1 proc
invoke MessageBox, 0, addr txt1, addr cap1, 0
ret
ThreadProc1 endp

ThreadProc2 proc
invoke MessageBox, 0, addr txt2, addr cap2, 0
ret
ThreadProc2 endp

end start

Si on execute le programme sous debugger et qu'on laisse un breakpoint sur l'appel à l'API MessageBox (text3,cap3) RIEN NE SE PASSE > c'est logique vu qu'on sait que sous debugger CreateThread ne fonctionne qu'après avoir donné la main à windows. Toujours sous debugger, si on passe l'API MessageBox (text3,cap3), là du coup le premier CreateThread effectue le ThreadProc 0_0

**Mayti4** · 29/07/2006, 14h22

C'est que le debugger suspend tous les threads quand il rencontre un breakpoint.

Ca doit être le comportement par défaut d'ailleurs.

**backtothend** · 29/07/2006, 15h07

Tout à fait d'accord avec ta théorie Mayti4.
Et c'est tout à fait prouvable :
Si après le CreateThread, on met ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
mov ecx, -1
retour:
nop
loopd retour

Si on met un breakpoint après le loop, le thread a effectué une partie de ses opérations. (voir toute)
Si on pose un breakpoint sur le mov ecx, -1 , le thread n'étant pas encore executé, le debugger le suspend et c'est comme si le CreateThread n'avait pas eu lieu.
Il faut donc un minimum de temps avant que le ThreadProc ne s'execute après le CreateThread. Je viens de faire un calcul. Apperement il faut 22 millisecondes pour que les premières instructions du ThreadProc soient executés. (sur un p4, 3ghz)

**Médinoc** · 29/07/2006, 19h00

Et que se passe-t-il si, comme je l'ai dit, tu augmentes la priorité du thread ?

Et pour la dernière fois, Où A-TU VU DANS LA DOC QUE CreateThread() ACCEPTAIT UN PARAMETRE DE PRIORITÉ ?
Pas ici, en tout cas...

**Hibou57** · 29/07/2006, 19h33

Envoyé par backtothend

Salut.

Alors j'aimerais vous poser plusieurs questions :
*à quoi peut servir un child process?
>est ce qu'avec la création d'un child process, on peut executer deux instructions à la fois ? (1 pour le process mère et 1 pour le child process)
>est-ce que le child process peut accéder aux .data du process mère ?
*comment créer un child process ? quels APIs ?

Oops, désolé, j'arrive un peu tard, mais il peut-être encore temps pour une petite réponse résumée.

Il faut distingué le processus enfant, et le thread.

Le processus enfant peu partager certaines donnée du processus père (surtout les handles : handles de fichiers par exemple), il s'execute dans un autre espace d'adressage que sont parent.

Le thread est une solution plus légère. Il peut partager toutes les données du son parent (qui n'est d'ailleurs pas vraiment un parent), puisqu'il s'execute dans le même espace d'adressage.

D'autres différences plus technique : le processus enfant est plus lourd, parce qu'il y a commutation de certains registres systèmes du processeur, qui sont long à se charger, parce que leur chargement à énormément de conscéquence secondaire.

Le thread est moins fiable que le processus enfant, parce que si le le programme plante, alors le thread plante aussi. Il y avait par exemple une option que j'utilisais avec IE5 (je ne la trouve plus avec IE6, alors je ne sais pas ce qu'elle est devenue), qui permettait que l'ouverture de chaque nouvelle fenêtre se fasse dans un processus séparé. Ainsi, si un fenêtre se plantait, les autres ne plantait pas. Tandis qu'avec IE6, pour lequel je ne trouve pas d'accès à cette option, si une fenêtre plante, alors toutes les autres plantent aussi.

Dans une application typique, on utilise un processus enfant pour l'interface utilisateur (si elle est assez conscéquente), et un autre pour le coeur fonctionel de l'application. Ainsi, si par exemple un fonction de l'application longue à executer est en cours, alors l'interface utilisateur continue quand même de répondre (même si certaines commandes seront probablement désactivées).

Il est bon de ne pas trop multiplié les processus enfant, à cause de la consomation de resource que représente la commutation d'une processus à l'autre. Les threads pourront être mutiplier avec moins de conscéquences.

Le thread s'emploie pour des raisons d'organisation du coeur de l'application. Par exemple, dans une application reseau, l'écoute passive sur un port, sera typiquement détaché en un thread séparé. La gestion des logs des messages de l'application pourra aussi faire l'objet d'un thread, l'oscultation de l'état de l'application étant conceptuellement parralèle au fonctionnement fondamental de l'application.

Je ne sais pas si ça répond bien exactement à ta question, mais je l'ai écrit en pensant que ça pourrait servire à d'autres quand même au moins.

**backtothend** · 29/07/2006, 19h42

Envoyé par Médinoc

Et que se passe-t-il si, comme je l'ai dit, tu augmentes la priorité du thread ?

Et pour la dernière fois, Où A-TU VU DANS LA DOC QUE CreateThread() ACCEPTAIT UN PARAMETRE DE PRIORITÉ ?
Pas ici, en tout cas...

Désolé, erreur de ma part. Le paramètre de priorité je l'ai ajouté après ton intervention plus haut et où je n'avais pas compris comment l'API marchait. J'ai remplacé par un Null par après. (pour qu'il run immédiatement le thread)
Sinon he bien si on augmente la priorité ProcThread est éxecuté plus vite. J'ai testé avec la priorité la plus haute et ProcThread s'execute après 1 (environ) millièmes de secondes.
J'ai vu également que la taille du stack était fixé à 1 mb par défault. Si on utilise l'API GlobalAlloc elle peut renvoyé un buffer avec un maximum de 1mb de capacité?

Sinon merci Hibou57 pour le complément d'informations et d'exemples.

**Médinoc** · 29/07/2006, 21h22

Ppour le paramètre de CreateThread(), tu devrais mettre 0 plutot que NULL (c'est une valeur, pas un pointeur, et sous Win64, ça n'aura pas la même taille).

Et je ne comprends pas ta question à propos de GlobalAlloc() : GlobalAlloc() alloue de la mémoire sur le tas --> Quel rapport avec la taille de la pile ?

**backtothend** · 29/07/2006, 22h59

Non rien. C'est parce que j'ai vu qu'on pouvait donner une variable à ThreadProc en paramètre avec CreateThread... (je pensais à un buffer non limité...)
Enfin de toute façon j'ai résolu mon problème. Merci encore à tous!

Child Process, c'est quoi ?

Windows

Discussions similaires

Partager

Partager