Je ne parviens pas à trouver la réponse à cette question : est-ce que
le signal SIGCHLD est reçu pour la mort des fils que j'ai créés
explicitement ou est-ce que je peux le recevoir dans certains cas pour
les fils de mes fils ? Ou est-ce réservé à init (qui peut adopter des
fils qui ne sont pas les siens) ?
--
if (user_specified)
/* Didn't work, but the user is convinced this is the
* place. */
2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c
Je ne parviens pas à trouver la réponse à cette question : est-ce que le signal SIGCHLD est reçu pour la mort des fils que j'ai créés explicitement ou est-ce que je peux le recevoir dans certains cas pour les fils de mes fils ? Ou est-ce réservé à init (qui peut adopter des fils qui ne sont pas les siens) ?
$ bash $ appli-qui-dure & $ exec mon-programme
mon-programme recevrai SIGCHLD après la fin de l'exécution de appli-qui-dure.
"laisser sa carte à une fille, c'est comme jeter une bouteille à la mer" -- manu
Coucou !
Je ne parviens pas à trouver la réponse à cette question : est-ce que
le signal SIGCHLD est reçu pour la mort des fils que j'ai créés
explicitement ou est-ce que je peux le recevoir dans certains cas pour
les fils de mes fils ? Ou est-ce réservé à init (qui peut adopter des
fils qui ne sont pas les siens) ?
$ bash
$ appli-qui-dure &
$ exec mon-programme
mon-programme recevrai SIGCHLD après la fin de l'exécution de
appli-qui-dure.
Je ne parviens pas à trouver la réponse à cette question : est-ce que le signal SIGCHLD est reçu pour la mort des fils que j'ai créés explicitement ou est-ce que je peux le recevoir dans certains cas pour les fils de mes fils ? Ou est-ce réservé à init (qui peut adopter des fils qui ne sont pas les siens) ?
$ bash $ appli-qui-dure & $ exec mon-programme
mon-programme recevrai SIGCHLD après la fin de l'exécution de appli-qui-dure.
"laisser sa carte à une fille, c'est comme jeter une bouteille à la mer" -- manu
Laurent Wacrenier
Vincent Bernat écrit:
Je ne parviens pas à trouver la réponse à cette question : est-ce que le signal SIGCHLD est reçu pour la mort des fils que j'ai créés explicitement ou est-ce que je peux le recevoir dans certains cas pour les fils de mes fils ? Ou est-ce réservé à init (qui peut adopter des fils qui ne sont pas les siens) ?
Par défaut, SIGCHLD est reçu par le père à chaque changement d'état des fils (terminaison, suspension, reprise), pas des petits-fils.
Le processus 1 (init) récupère traditionellement la paternité des processus orphelins.
Vincent Bernat <vincent.bernat@raysa.org> écrit:
Je ne parviens pas à trouver la réponse à cette question : est-ce que
le signal SIGCHLD est reçu pour la mort des fils que j'ai créés
explicitement ou est-ce que je peux le recevoir dans certains cas pour
les fils de mes fils ? Ou est-ce réservé à init (qui peut adopter des
fils qui ne sont pas les siens) ?
Par défaut, SIGCHLD est reçu par le père à chaque changement d'état
des fils (terminaison, suspension, reprise), pas des petits-fils.
Le processus 1 (init) récupère traditionellement la paternité des
processus orphelins.
Je ne parviens pas à trouver la réponse à cette question : est-ce que le signal SIGCHLD est reçu pour la mort des fils que j'ai créés explicitement ou est-ce que je peux le recevoir dans certains cas pour les fils de mes fils ? Ou est-ce réservé à init (qui peut adopter des fils qui ne sont pas les siens) ?
Par défaut, SIGCHLD est reçu par le père à chaque changement d'état des fils (terminaison, suspension, reprise), pas des petits-fils.
Le processus 1 (init) récupère traditionellement la paternité des processus orphelins.
Laurent Wacrenier
DINH Viêt Hoà écrit:
$ bash $ appli-qui-dure & $ exec mon-programme
mon-programme recevrai SIGCHLD après la fin de l'exécution de appli-qui-dure.
C'est toujours le même processus, même si le code a été changé.
DINH Viêt Hoà <dinh.viet.hoa@free.fr> écrit:
$ bash
$ appli-qui-dure &
$ exec mon-programme
mon-programme recevrai SIGCHLD après la fin de l'exécution de
appli-qui-dure.
C'est toujours le même processus, même si le code a été changé.
mon-programme recevrai SIGCHLD après la fin de l'exécution de appli-qui-dure.
C'est toujours le même processus, même si le code a été changé.
drkm
Laurent Wacrenier <lwa@ teaser . fr> writes:
DINH Viêt Hoà écrit:
$ bash $ appli-qui-dure & $ exec mon-programme
mon-programme recevrai SIGCHLD après la fin de l'exécution de appli-qui-dure.
C'est toujours le même processus, même si le code a été changé.
Bien sûr. Mais ça veut dire qu'un processus peut recevoir un `SIGCHLD' même lorsque le programme dont il est une instance ne crée jamais de processus.
On ne peut donc pas supposer, lorsque l'on développe un tel programme, qu'il ne recevra pas de `SIGCHLD'. Maintenant, quant à l'utilité de savoir cela durant ce développement ...
--drkm
Laurent Wacrenier <lwa@ teaser . fr> writes:
DINH Viêt Hoà <dinh.viet.hoa@free.fr> écrit:
$ bash
$ appli-qui-dure &
$ exec mon-programme
mon-programme recevrai SIGCHLD après la fin de l'exécution de
appli-qui-dure.
C'est toujours le même processus, même si le code a été changé.
Bien sûr. Mais ça veut dire qu'un processus peut recevoir un
`SIGCHLD' même lorsque le programme dont il est une instance ne crée
jamais de processus.
On ne peut donc pas supposer, lorsque l'on développe un tel
programme, qu'il ne recevra pas de `SIGCHLD'. Maintenant, quant à
l'utilité de savoir cela durant ce développement ...
mon-programme recevrai SIGCHLD après la fin de l'exécution de appli-qui-dure.
C'est toujours le même processus, même si le code a été changé.
Bien sûr. Mais ça veut dire qu'un processus peut recevoir un `SIGCHLD' même lorsque le programme dont il est une instance ne crée jamais de processus.
On ne peut donc pas supposer, lorsque l'on développe un tel programme, qu'il ne recevra pas de `SIGCHLD'. Maintenant, quant à l'utilité de savoir cela durant ce développement ...
--drkm
Laurent Wacrenier
drkm écrit:
On ne peut donc pas supposer, lorsque l'on développe un tel programme, qu'il ne recevra pas de `SIGCHLD'. Maintenant, quant à l'utilité de savoir cela durant ce développement ...
Je ne l'avais pas vu comme ça.
Si on ne crée pas de fils, il n'y a aucune raison de changer l'action par défaut de SIGCHLD (qui est d'ignorer le signal). Là où ça peut devenir embétant, c'est si on crée un fils, qu'on attent sa terminaison et qu'on suppose que le premier SIGCHLD reçu vient de sa terminaison alors qu'il convient de noter le PID du fils et de vérifier qu'il est bien terminé.
drkm <usenet@fgeorges.org> écrit:
On ne peut donc pas supposer, lorsque l'on développe un tel
programme, qu'il ne recevra pas de `SIGCHLD'. Maintenant, quant à
l'utilité de savoir cela durant ce développement ...
Je ne l'avais pas vu comme ça.
Si on ne crée pas de fils, il n'y a aucune raison de changer l'action
par défaut de SIGCHLD (qui est d'ignorer le signal). Là où ça peut
devenir embétant, c'est si on crée un fils, qu'on attent sa
terminaison et qu'on suppose que le premier SIGCHLD reçu vient de sa
terminaison alors qu'il convient de noter le PID du fils et de
vérifier qu'il est bien terminé.
On ne peut donc pas supposer, lorsque l'on développe un tel programme, qu'il ne recevra pas de `SIGCHLD'. Maintenant, quant à l'utilité de savoir cela durant ce développement ...
Je ne l'avais pas vu comme ça.
Si on ne crée pas de fils, il n'y a aucune raison de changer l'action par défaut de SIGCHLD (qui est d'ignorer le signal). Là où ça peut devenir embétant, c'est si on crée un fils, qu'on attent sa terminaison et qu'on suppose que le premier SIGCHLD reçu vient de sa terminaison alors qu'il convient de noter le PID du fils et de vérifier qu'il est bien terminé.
DINH Viêt Hoà
Je ne l'avais pas vu comme ça.
Si on ne crée pas de fils, il n'y a aucune raison de changer l'action par défaut de SIGCHLD (qui est d'ignorer le signal). Là où ça peut devenir embétant, c'est si on crée un fils, qu'on attent sa terminaison et qu'on suppose que le premier SIGCHLD reçu vient de sa terminaison alors qu'il convient de noter le PID du fils et de vérifier qu'il est bien terminé.
Je pense que c'est le programme parent qui fait l'exec() qui a la responsabilité de se faire remplacer que par des processus qui gèrent le SIGCHLD si jamais le programme parent a potentiellement des fils.
-- DINH V. Hoa,
"monde de merde" -- Erwan David
Je ne l'avais pas vu comme ça.
Si on ne crée pas de fils, il n'y a aucune raison de changer l'action
par défaut de SIGCHLD (qui est d'ignorer le signal). Là où ça peut
devenir embétant, c'est si on crée un fils, qu'on attent sa
terminaison et qu'on suppose que le premier SIGCHLD reçu vient de sa
terminaison alors qu'il convient de noter le PID du fils et de
vérifier qu'il est bien terminé.
Je pense que c'est le programme parent qui fait l'exec() qui a la
responsabilité de se faire remplacer que par des processus qui gèrent le
SIGCHLD si jamais le programme parent a potentiellement des fils.
Si on ne crée pas de fils, il n'y a aucune raison de changer l'action par défaut de SIGCHLD (qui est d'ignorer le signal). Là où ça peut devenir embétant, c'est si on crée un fils, qu'on attent sa terminaison et qu'on suppose que le premier SIGCHLD reçu vient de sa terminaison alors qu'il convient de noter le PID du fils et de vérifier qu'il est bien terminé.
Je pense que c'est le programme parent qui fait l'exec() qui a la responsabilité de se faire remplacer que par des processus qui gèrent le SIGCHLD si jamais le programme parent a potentiellement des fils.
-- DINH V. Hoa,
"monde de merde" -- Erwan David
Laurent Wacrenier
DINH Viêt Hoà écrit:
Je pense que c'est le programme parent qui fait l'exec() qui a la responsabilité de se faire remplacer que par des processus qui gèrent le SIGCHLD si jamais le programme parent a potentiellement des fils.
SIGCHLD est ignoré après l'exec. Tout ira bien si le nouvel executable ne gère pas spécialement de processus fils.
De toute façon on peut toujours lancer des "kill -CHLD" sur un processus.
DINH Viêt Hoà <dinh.viet.hoa@free.fr> écrit:
Je pense que c'est le programme parent qui fait l'exec() qui a la
responsabilité de se faire remplacer que par des processus qui gèrent le
SIGCHLD si jamais le programme parent a potentiellement des fils.
SIGCHLD est ignoré après l'exec. Tout ira bien si le nouvel executable
ne gère pas spécialement de processus fils.
De toute façon on peut toujours lancer des "kill -CHLD" sur un
processus.
Je pense que c'est le programme parent qui fait l'exec() qui a la responsabilité de se faire remplacer que par des processus qui gèrent le SIGCHLD si jamais le programme parent a potentiellement des fils.
SIGCHLD est ignoré après l'exec. Tout ira bien si le nouvel executable ne gère pas spécialement de processus fils.
De toute façon on peut toujours lancer des "kill -CHLD" sur un processus.
DINH Viêt Hoà
DINH Viêt Hoà écrit:
Je pense que c'est le programme parent qui fait l'exec() qui a la responsabilité de se faire remplacer que par des processus qui gèrent le SIGCHLD si jamais le programme parent a potentiellement des fils.
SIGCHLD est ignoré après l'exec. Tout ira bien si le nouvel executable ne gère pas spécialement de processus fils.
hum ... les processus fils seront zombie si jamais aucun wait() n'est fait dessus à leur terminaison.
-- DINH V. Hoa,
"monde de merde" -- Erwan David
DINH Viêt Hoà <dinh.viet.hoa@free.fr> écrit:
Je pense que c'est le programme parent qui fait l'exec() qui a la
responsabilité de se faire remplacer que par des processus qui gèrent le
SIGCHLD si jamais le programme parent a potentiellement des fils.
SIGCHLD est ignoré après l'exec. Tout ira bien si le nouvel executable
ne gère pas spécialement de processus fils.
hum ... les processus fils seront zombie si jamais aucun wait() n'est
fait dessus à leur terminaison.
Je pense que c'est le programme parent qui fait l'exec() qui a la responsabilité de se faire remplacer que par des processus qui gèrent le SIGCHLD si jamais le programme parent a potentiellement des fils.
SIGCHLD est ignoré après l'exec. Tout ira bien si le nouvel executable ne gère pas spécialement de processus fils.
hum ... les processus fils seront zombie si jamais aucun wait() n'est fait dessus à leur terminaison.
-- DINH V. Hoa,
"monde de merde" -- Erwan David
Laurent Wacrenier
DINH Viêt Hoà écrit:
SIGCHLD est ignoré après l'exec. Tout ira bien si le nouvel executable ne gère pas spécialement de processus fils.
hum ... les processus fils seront zombie si jamais aucun wait() n'est fait dessus à leur terminaison.
Pas quand le processus père ignore SIGCHLD.
DINH Viêt Hoà <dinh.viet.hoa@free.fr> écrit:
SIGCHLD est ignoré après l'exec. Tout ira bien si le nouvel executable
ne gère pas spécialement de processus fils.
hum ... les processus fils seront zombie si jamais aucun wait() n'est
fait dessus à leur terminaison.
SIGCHLD est ignoré après l'exec. Tout ira bien si le nouvel executable ne gère pas spécialement de processus fils.
hum ... les processus fils seront zombie si jamais aucun wait() n'est fait dessus à leur terminaison.
Pas quand le processus père ignore SIGCHLD.
DINH Viêt Hoà
DINH Viêt Hoà écrit:
SIGCHLD est ignoré après l'exec. Tout ira bien si le nouvel executable ne gère pas spécialement de processus fils.
hum ... les processus fils seront zombie si jamais aucun wait() n'est fait dessus à leur terminaison.
Pas quand le processus père ignore SIGCHLD.
alors j'avais un phénomène bizarre. Genre à la fin de mon .xsession, j'ai eu un exec xclock à la fin. Ce qui faisait que tous les processus que je terminai devenai zombie. Cela voudrait dire que xclock n'ignore pas SIGCHLD ? ou quand tu parles du processus père, tu parles du processus père avant exec() ?
-- DINH V. Hoa,
"monde de merde" -- Erwan David
DINH Viêt Hoà <dinh.viet.hoa@free.fr> écrit:
SIGCHLD est ignoré après l'exec. Tout ira bien si le nouvel executable
ne gère pas spécialement de processus fils.
hum ... les processus fils seront zombie si jamais aucun wait() n'est
fait dessus à leur terminaison.
Pas quand le processus père ignore SIGCHLD.
alors j'avais un phénomène bizarre.
Genre à la fin de mon .xsession, j'ai eu un exec xclock à la fin.
Ce qui faisait que tous les processus que je terminai devenai zombie.
Cela voudrait dire que xclock n'ignore pas SIGCHLD ?
ou quand tu parles du processus père, tu parles du processus père avant
exec() ?
SIGCHLD est ignoré après l'exec. Tout ira bien si le nouvel executable ne gère pas spécialement de processus fils.
hum ... les processus fils seront zombie si jamais aucun wait() n'est fait dessus à leur terminaison.
Pas quand le processus père ignore SIGCHLD.
alors j'avais un phénomène bizarre. Genre à la fin de mon .xsession, j'ai eu un exec xclock à la fin. Ce qui faisait que tous les processus que je terminai devenai zombie. Cela voudrait dire que xclock n'ignore pas SIGCHLD ? ou quand tu parles du processus père, tu parles du processus père avant exec() ?
