Suite à mes interrogations sur les pipes en C, j'ai un autre petit
truc à vous soumettre... J'ai googlisé, RTFMer sans trop de succès.
Comment puis-je à partir d'un programme écrit en C surveiller qu'un
processus n'est pas mort (en fait, le processus fils généré par le
fork(), pour pouvoir fermer mon pipe() du côté du père.) ?
J'aimerais aussi que ce soit portable...
Je crois que c'est ce que je vais faire. kill(pid, 0) me renvoie un code d'erreur non documenté (122 !).
Tu tournes sous quel système ?
JKB
Le 17-12-2004, à propos de Re: Surveiller la vie d'un processus (en C), Miod Vallat écrivait dans fr.comp.os.unix :
Je crois que c'est ce que je vais faire. kill(pid, 0) me renvoie un code d'erreur non documenté (122 !).
Tu tournes sous quel système ?
J'ai fait le test sur un Linux/Sparc. 122 ne correspond à aucune des valeurs censées être retournée par kill() dans errno qui sont 22 (EINVAL), 1 (EPERM) ou 3 (ESRCH). kill() renvoie pourtant bien une erreur. Si j'ai le courage, je ferai un test sous Solaris, mais je vais devoir rebooter le ronrondrome de Schroedinger ;-)
JKB
Le 17-12-2004, à propos de
Re: Surveiller la vie d'un processus (en C),
Miod Vallat écrivait dans fr.comp.os.unix :
Je crois que c'est ce que je vais faire. kill(pid, 0) me renvoie un
code d'erreur non documenté (122 !).
Tu tournes sous quel système ?
J'ai fait le test sur un Linux/Sparc. 122 ne correspond à aucune des
valeurs censées être retournée par kill() dans errno qui sont 22 (EINVAL),
1 (EPERM) ou 3 (ESRCH). kill() renvoie pourtant bien une erreur.
Si j'ai le courage, je ferai un test sous Solaris, mais je vais devoir
rebooter le ronrondrome de Schroedinger ;-)
Le 17-12-2004, à propos de Re: Surveiller la vie d'un processus (en C), Miod Vallat écrivait dans fr.comp.os.unix :
Je crois que c'est ce que je vais faire. kill(pid, 0) me renvoie un code d'erreur non documenté (122 !).
Tu tournes sous quel système ?
J'ai fait le test sur un Linux/Sparc. 122 ne correspond à aucune des valeurs censées être retournée par kill() dans errno qui sont 22 (EINVAL), 1 (EPERM) ou 3 (ESRCH). kill() renvoie pourtant bien une erreur. Si j'ai le courage, je ferai un test sous Solaris, mais je vais devoir rebooter le ronrondrome de Schroedinger ;-)
JKB
Miod Vallat
Tu tournes sous quel système ?
J'ai fait le test sur un Linux/Sparc. 122 ne correspond à aucune des valeurs censées être retournée par kill() dans errno qui sont 22 (EINVAL), 1 (EPERM) ou 3 (ESRCH). kill() renvoie pourtant bien une erreur. Si j'ai le courage, je ferai un test sous Solaris, mais je vais devoir rebooter le ronrondrome de Schroedinger ;-)
Et EILSEQ n'est utilisé que dans le code usb, blootooth, et deux systèmes de fichiers.
Amusant.
Tu tournes sous quel système ?
J'ai fait le test sur un Linux/Sparc. 122 ne correspond à aucune des
valeurs censées être retournée par kill() dans errno qui sont 22 (EINVAL),
1 (EPERM) ou 3 (ESRCH). kill() renvoie pourtant bien une erreur.
Si j'ai le courage, je ferai un test sous Solaris, mais je vais devoir
rebooter le ronrondrome de Schroedinger ;-)
J'ai fait le test sur un Linux/Sparc. 122 ne correspond à aucune des valeurs censées être retournée par kill() dans errno qui sont 22 (EINVAL), 1 (EPERM) ou 3 (ESRCH). kill() renvoie pourtant bien une erreur. Si j'ai le courage, je ferai un test sous Solaris, mais je vais devoir rebooter le ronrondrome de Schroedinger ;-)
Et EILSEQ n'est utilisé que dans le code usb, blootooth, et deux systèmes de fichiers.
Amusant.
JKB
Le 17-12-2004, à propos de Re: Surveiller la vie d'un processus (en C), Miod Vallat écrivait dans fr.comp.os.unix :
Tu tournes sous quel système ?
J'ai fait le test sur un Linux/Sparc. 122 ne correspond à aucune des valeurs censées être retournée par kill() dans errno qui sont 22 (EINVAL), 1 (EPERM) ou 3 (ESRCH). kill() renvoie pourtant bien une erreur. Si j'ai le courage, je ferai un test sous Solaris, mais je vais devoir rebooter le ronrondrome de Schroedinger ;-)
Et EILSEQ n'est utilisé que dans le code usb, blootooth, et deux systèmes de fichiers.
Amusant.
Oui, bizarre...
JKB
Le 17-12-2004, à propos de
Re: Surveiller la vie d'un processus (en C),
Miod Vallat écrivait dans fr.comp.os.unix :
Tu tournes sous quel système ?
J'ai fait le test sur un Linux/Sparc. 122 ne correspond à aucune des
valeurs censées être retournée par kill() dans errno qui sont 22 (EINVAL),
1 (EPERM) ou 3 (ESRCH). kill() renvoie pourtant bien une erreur.
Si j'ai le courage, je ferai un test sous Solaris, mais je vais devoir
rebooter le ronrondrome de Schroedinger ;-)
Le 17-12-2004, à propos de Re: Surveiller la vie d'un processus (en C), Miod Vallat écrivait dans fr.comp.os.unix :
Tu tournes sous quel système ?
J'ai fait le test sur un Linux/Sparc. 122 ne correspond à aucune des valeurs censées être retournée par kill() dans errno qui sont 22 (EINVAL), 1 (EPERM) ou 3 (ESRCH). kill() renvoie pourtant bien une erreur. Si j'ai le courage, je ferai un test sous Solaris, mais je vais devoir rebooter le ronrondrome de Schroedinger ;-)
Et EILSEQ n'est utilisé que dans le code usb, blootooth, et deux systèmes de fichiers.
Amusant.
Oui, bizarre...
JKB
Alain Ketterlin
JKB writes:
Suite à mes interrogations sur les pipes en C, j'ai un autre petit truc à vous soumettre... J'ai googlisé, RTFMer sans trop de succès. Comment puis-je à partir d'un programme écrit en C surveiller qu'un processus n'est pas mort (en fait, le processus fils généré par le fork(), pour pouvoir fermer mon pipe() du côté du père.) ?
waitpid(2) avec l'option WNOHANG ?
J'aimerais aussi que ce soit portable...
Il est dit que c'est POSIX dans la page de man (sous linux 2.6). A verifier.
-- Alain.
JKB <knatschke@chezmoi.com> writes:
Suite à mes interrogations sur les pipes en C, j'ai un autre petit
truc à vous soumettre... J'ai googlisé, RTFMer sans trop de succès.
Comment puis-je à partir d'un programme écrit en C surveiller qu'un
processus n'est pas mort (en fait, le processus fils généré par le
fork(), pour pouvoir fermer mon pipe() du côté du père.) ?
waitpid(2) avec l'option WNOHANG ?
J'aimerais aussi que ce soit portable...
Il est dit que c'est POSIX dans la page de man (sous linux 2.6). A
verifier.
Suite à mes interrogations sur les pipes en C, j'ai un autre petit truc à vous soumettre... J'ai googlisé, RTFMer sans trop de succès. Comment puis-je à partir d'un programme écrit en C surveiller qu'un processus n'est pas mort (en fait, le processus fils généré par le fork(), pour pouvoir fermer mon pipe() du côté du père.) ?
waitpid(2) avec l'option WNOHANG ?
J'aimerais aussi que ce soit portable...
Il est dit que c'est POSIX dans la page de man (sous linux 2.6). A verifier.
-- Alain.
Nicolas George
Laurent Wacrenier wrote in message :
On a un SIGPIPE quand on essaye d'écrire dans un PIPE et que l'autre extremité est fermée.
Précisons encore : seulement à la deuxième tentative d'écriture (et plus tard si on a survécu), la première signalera une condition de fin de fichier (0 octets écrits).
Laurent Wacrenier wrote in message
<slrncs5ram.1fr2.lwa@victor.teaser.fr>:
On a un SIGPIPE quand on essaye d'écrire dans un PIPE et que l'autre
extremité est fermée.
Précisons encore : seulement à la deuxième tentative d'écriture (et plus
tard si on a survécu), la première signalera une condition de fin de fichier
(0 octets écrits).
On a un SIGPIPE quand on essaye d'écrire dans un PIPE et que l'autre extremité est fermée.
Précisons encore : seulement à la deuxième tentative d'écriture (et plus tard si on a survécu), la première signalera une condition de fin de fichier (0 octets écrits).
Stephane Chazelas
2004-12-17, 18:11(+00), Nicolas George:
Laurent Wacrenier wrote in message :
On a un SIGPIPE quand on essaye d'écrire dans un PIPE et que l'autre extremité est fermée.
Précisons encore : seulement à la deuxième tentative d'écriture (et plus tard si on a survécu), la première signalera une condition de fin de fichier (0 octets écrits).
??? Sur quel systeme ?
-- Stephane
2004-12-17, 18:11(+00), Nicolas George:
Laurent Wacrenier wrote in message
<slrncs5ram.1fr2.lwa@victor.teaser.fr>:
On a un SIGPIPE quand on essaye d'écrire dans un PIPE et que l'autre
extremité est fermée.
Précisons encore : seulement à la deuxième tentative d'écriture (et plus
tard si on a survécu), la première signalera une condition de fin de fichier
(0 octets écrits).
On a un SIGPIPE quand on essaye d'écrire dans un PIPE et que l'autre extremité est fermée.
Précisons encore : seulement à la deuxième tentative d'écriture (et plus tard si on a survécu), la première signalera une condition de fin de fichier (0 octets écrits).
??? Sur quel systeme ?
-- Stephane
DINH Viêt Hoà
Laurent Wacrenier wrote in message :
On a un SIGPIPE quand on essaye d'écrire dans un PIPE et que l'autre extremité est fermée.
Précisons encore : seulement à la deuxième tentative d'écriture (et plus tard si on a survécu), la première signalera une condition de fin de fichier (0 octets écrits).
extrait du manuel POSIX :
<< An attempt is made to write to a pipe or FIFO that is not open for reading by any process, or that only has one end open. A SIGPIPE signal shall also be sent to the thread.
Il n'indique pas le comportement que tu décris. Où as-tu lu cela ?
-- DINH V. Hoa,
"tu as bientot 15 ans, faut que tu commences à être autonome" -- jul
Laurent Wacrenier wrote in message
<slrncs5ram.1fr2.lwa@victor.teaser.fr>:
On a un SIGPIPE quand on essaye d'écrire dans un PIPE et que l'autre
extremité est fermée.
Précisons encore : seulement à la deuxième tentative d'écriture (et plus
tard si on a survécu), la première signalera une condition de fin de fichier
(0 octets écrits).
extrait du manuel POSIX :
<<
An attempt is made to write to a pipe or FIFO that is not open for
reading by any process, or that only has one end open. A SIGPIPE signal
shall also be sent to the thread.
Il n'indique pas le comportement que tu décris.
Où as-tu lu cela ?
--
DINH V. Hoa,
"tu as bientot 15 ans, faut que tu commences à être autonome" -- jul
On a un SIGPIPE quand on essaye d'écrire dans un PIPE et que l'autre extremité est fermée.
Précisons encore : seulement à la deuxième tentative d'écriture (et plus tard si on a survécu), la première signalera une condition de fin de fichier (0 octets écrits).
extrait du manuel POSIX :
<< An attempt is made to write to a pipe or FIFO that is not open for reading by any process, or that only has one end open. A SIGPIPE signal shall also be sent to the thread.
Il n'indique pas le comportement que tu décris. Où as-tu lu cela ?
-- DINH V. Hoa,
"tu as bientot 15 ans, faut que tu commences à être autonome" -- jul
DINH Viêt Hoà
Le 17-12-2004, à propos de Re: Surveiller la vie d'un processus (en C), Eric Jacoboni écrivait dans fr.comp.os.unix :
JKB writes:
Envoyer un kill(pid, 0) ?
Groumphfff... J'ai tout cherché et je l'avais sous les lunettes...
Cela dit, comme on l'a dit plus haut, le détournement de SIGCHLD me semble plus "propre" lorsqu'il s'agit, pour un père, de savoir que son fils est mort.
Je crois que c'est ce que je vais faire. kill(pid, 0) me renvoie un code d'erreur non documenté (122 !).
Je crois qu'Eric parlait plutôt de l'interception du signal SIGCHLD et non pas de kill(pid, 0)
-- DINH V. Hoa,
"tu as bientot 15 ans, faut que tu commences à être autonome" -- jul
Le 17-12-2004, à propos de
Re: Surveiller la vie d'un processus (en C),
Eric Jacoboni écrivait dans fr.comp.os.unix :
JKB <knatschke@chezmoi.com> writes:
Envoyer un kill(pid, 0) ?
Groumphfff... J'ai tout cherché et je l'avais sous les lunettes...
Cela dit, comme on l'a dit plus haut, le détournement de SIGCHLD me
semble plus "propre" lorsqu'il s'agit, pour un père, de savoir que son
fils est mort.
Je crois que c'est ce que je vais faire. kill(pid, 0) me renvoie un
code d'erreur non documenté (122 !).
Je crois qu'Eric parlait plutôt de l'interception du signal SIGCHLD et
non pas de kill(pid, 0)
--
DINH V. Hoa,
"tu as bientot 15 ans, faut que tu commences à être autonome" -- jul
Le 17-12-2004, à propos de Re: Surveiller la vie d'un processus (en C), Eric Jacoboni écrivait dans fr.comp.os.unix :
JKB writes:
Envoyer un kill(pid, 0) ?
Groumphfff... J'ai tout cherché et je l'avais sous les lunettes...
Cela dit, comme on l'a dit plus haut, le détournement de SIGCHLD me semble plus "propre" lorsqu'il s'agit, pour un père, de savoir que son fils est mort.
Je crois que c'est ce que je vais faire. kill(pid, 0) me renvoie un code d'erreur non documenté (122 !).
Je crois qu'Eric parlait plutôt de l'interception du signal SIGCHLD et non pas de kill(pid, 0)
-- DINH V. Hoa,
"tu as bientot 15 ans, faut que tu commences à être autonome" -- jul
Nicolas George
Stephane Chazelas wrote in message :
??? Sur quel systeme ?
Effectivement, j'ai halluciné. J'étais persuadé que c'était le comportement avec les sockets, mais même là, je n'arrive pas à le reproduire.
Stephane Chazelas wrote in message
<slrncs6eis.f58.stephane.chazelas@spam.is.invalid>:
??? Sur quel systeme ?
Effectivement, j'ai halluciné. J'étais persuadé que c'était le comportement
avec les sockets, mais même là, je n'arrive pas à le reproduire.
