Discussion :

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

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]

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]

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]

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]

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]

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.

[Hibou57]

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.