Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] wait, waitpid - Attendre la fin d'un processus. [size=18] [b]Résumé[/b] [/size] [b]#include <sys/types.h>[/b] [b][/b] [b]#include <sys/wait.h>[/b] [b][i]pid_t wait (int * status );[/i][/b] [b][/b] [b][i]pid_t waitpid (pid_t pid , int * status , int options );[/i][/b] [size=18] [b]Description[/b] [/size] La fonction [b]wait[/b] suspend l'exécution du processus courant jusqu'à ce qu'un enfant se termine, ou jusqu'à ce qu'un signal à intercepter arrive. Si un processus fils s'est déjà terminé au moment de l'appel (il est devenu "zombie"), la fonction revient immédiatement. Toutes les ressources utilisées par le fils sont libérées. La fonction [b]waitpid[/b] suspend l'exécution du processus courant jusqu'à ce que le processus fils numéro [i]pid[/i] se termine, ou jusqu'à ce qu'un signal à intercepter arrive. Si le fils mentionné par [i]pid[/i] s'est déjà terminé au moment de l'appel (il est devenu "zombie"), la fonction revient immédiatement. Toutes les ressources utilisées par le fils sont libérées. La valeur de [i]pid[/i] peut également être l'une des suivantes : "< -1" [table][row][col]    [/col][col]attendre la fin de n'importe quel processus fils appartenant à un groupe de processus d'ID [b]pid .[/b][/col][/row][/table] -1 [table][row][col]    [/col][col]attendre la fin de n'importe quel fils. C'est le même comportement que [b]wait.[/b][/col][/row][/table] 0 [table][row][col]    [/col][col]attendre la fin de n'importe quel processus fils du même groupe que l'appelant.[/col][/row][/table] "> 0" [table][row][col]    [/col][col]attendre la fin du processus numéro [b]pid .[/b][/col][/row][/table] La valeur de l'argument option [i]options[/i] est un [i]OU[/i] binaire entre les constantes suivantes : [b]WNOHANG[/b] [table][row][col]    [/col][col]ne pas bloquer si aucun fils ne s'est terminé.[/col][/row][/table] [b]WUNTRACED[/b] [table][row][col]    [/col][col]recevoir l'information concernant également les fils bloqués (mais non suivis par [b]trace (2))[/b] si on ne l'a pas encore reçue. L'état des fils suivis est fourni même sans cette option[/col][/row][/table] (Pour les options spécifiques à Linux, voir plus bas). Si [i]status[/i] est non [b]NULL ,[/b] [b]wait[/b] et [b]waitpid[/b] y stockent l'information sur la terminaison du fils. Cette information peut être analysée avec les macros suivantes, qui réclament en argument le buffer [i]status[/i] (un [b]int[/b], et non pas un pointeur sur ce buffer). [b][i]WIFEXITED( status )[/i][/b] [table][row][col]    [/col][col]non nul si le fils s'est terminé normalement[/col][/row][/table] [b][i]WEXITSTATUS( status )[/i][/b] [table][row][col]    [/col][col]donne le code de retour tel qu'il a été mentionné dans l'appel [b]exit()[/b] ou dans le [b]return[/b] de la routine [b]main.[/b] Cette macro ne peut être évaluée que si [b]WIFEXITED[/b] est non nul.[/col][/row][/table] [b][i]WIFSIGNALED( status )[/i][/b] [table][row][col]    [/col][col]indique que le fils s'est terminé à cause d'un signal non intercepté.[/col][/row][/table] [b][i]WTERMSIG( status )[/i][/b] [table][row][col]    [/col][col]donne le numéro du signal qui a causé la fin du fils. Cette macro ne peut être évaluée que si [b]WIFSIGNALED[/b] est non nul.[/col][/row][/table] [b][i]WIFSTOPPED( status )[/i][/b] [table][row][col]    [/col][col]indique que le fils est actuellement arrêté. Cette macro n'a de sens que si l'on a effectué l'appel avec l'option [b]WUNTRACED .[/b][/col][/row][/table] [b][i]WSTOPSIG( status )[/i][/b] [table][row][col]    [/col][col]donne le numéro du signal qui a causé l'arrêt du fils. Cette macro ne peut être évaluée que si [b]WIFSTOPPED[/b] est non nul.[/col][/row][/table]     Certaines versions d'Unix (Linux, Solaris, mais pas AIX ou SunOS) définissent aussi une macro [b][i]WCOREDUMP( status )[/i][/b] Pour vérifier si le processus fils a créé un fichier core. N'utilisez ceci qu'encadré par #ifdef WCOREDUMP ... #endif. [size=18] [b]Valeur renvoyée[/b] [/size] En cas de réussite, le PID du fils qui s'est terminé est renvoyé, en cas d'échec -1 est renvoyé et [i]errno[/i] contient le code d'erreur. Si [b]WNOHANG[/b] a été employé et qu'aucun fils ne s'est terminé, zéro est renvoyé. [size=18] [b]Erreurs[/b] [/size] [b]ECHILD[/b] [table][row][col]    [/col][col]Le processus indiqué par [i]pid[/i] n'existe pas, ou n'est pas un fils du processus appelant. (Ceci peut arriver pour son propre fils si l'action de SIGCHLD est placé sur SIG_IGN, voir également le passage de la section NOTES concernant les threads).[/col][/row][/table] [b]EINVAL[/b] [table][row][col]    [/col][col]L'argument [i]options[/i] est invalide.[/col][/row][/table] [b]EINTR[/b] [b]WNOHANG[/b] [table][row][col]    [/col][col]n'est pas indiqué, et un signal à intercepter ou [b]SIGCHLD[/b] a été reçu.[/col][/row][/table] [size=18] [b]Notes[/b] [/size] Les spécifications Single Unix décrivent un attribut SA_NOCLDWAIT (non supportés sous Linux) permettant (lorsqu'il est positionné) aux processus fils se terminant de ne pas devenir zombies, comme quand l'action pour SIGCHLD est fixée à SIG_IGN. Un appel à [i]wait()[/i] ou [i]waitpid()[/i] bloquera jusqu'à ce qu'un fils se termine, puis échouera avec [i]errno[/i] contenant ECHILD.     Le standard POSIX original laissait le comportement avec SIGCHLD à SIG_IGN non spécifié. Les standards ultérieurs, y compris SUSv2 et POSIX 1003.1-2001 spécifent que le comportement décrit ci-dessus est une option XSI. Linux ne se conforme pas au second des deux points décrits : Si un appel [b]wait () ou waitpid ()[/b] est fait alors que SIGCHLD est ignoré, alors l'appel se comportera comme si SIGCHLD n'était pas ignoré, c'est à dire qu'il bloquera jusqu'à la première fin d'un fils et renverra le PID et l'état du fils. [size=18] [b]SpÉcificitÉs linux[/b] [/size] Dans le noyau Linux, un thread ordonnancé par le noyau n'est pas différent d'un simple processus. En fait, un thread est juste un processus qui est créé à l'aide de la routine - spécifique Linux - [b]clone (2).[/b] Les routines portables, comme [b]pthread_create (3)[/b] sont implémentées en appelant [b]clone (2).[/b] Avant Linux 2.4, un thread était simplement un cas particulier de processus, et en conséquence un thread ne pouvait pas attendre les enfants d'un autre thread, même si ce dernier appartenait au même groupe de threads. Toutefois, POSIX réclame une telle fonctionnalité, et depuis Linux 2.4 un thread peut, par défaut, attendre les enfants des autres threads du même groupe.     Les [i]options[/i] suivantes sont spécifiques à Linux, et servent pour les enfants créés avec [b]clone (2).[/b] [b]__WCLONE[/b] [table][row][col]    [/col][col]Attendre uniquement des enfants clones. Sinon, attendre uniquement les enfants non-clones (un enfant "clone" est un enfant qui n'envoie pas de signal, ou un autre signal que [b]SIGCHLD[/b] à son père à sa terminaison). Cette option est ignorée si [b]__WALL[/b] est aussi indiqué.[/col][/row][/table] [b]__WALL[/b] [table][row][col]    [/col][col](Depuis Linux 2.4) Attendre tous les enfants, quelques soient leurs types (clone ou non-clone).[/col][/row][/table] [b]__WNOTHREAD[/b] [table][row][col]    [/col][col](Depuis Linux 2.4) Ne pas attendre les enfants des autres threads du même groupe de threads. Ceci était le cas par défaut avant Linux 2.4.[/col][/row][/table] [size=18] [b]Conformité[/b] [/size] SVr4, POSIX.1 [size=18] [b]Voir aussi[/b] [/size] [b]clone (2),[/b] [b]ptrace (2),[/b] [b]signal (2),[/b] [b]wait4 (2),[/b] [b]pthread_create (3),[/b] [b]signal (7)[/b] [size=18] [b]Traduction[/b] [/size] Christophe Blaess, 1996-2003.
Fichier