Ça a l'air un peu compliqué comme ça... En fait, c'est assez simple.
Pour synchroniser le processus fils avec le processus père, j'envoie
un signal SIGSTART (en fait SIGUSR2) vers le processus fils qui
boucle sur un sigpending (le signal SIGSTART a été bloqué au
préalable).
Problème : sous Linux et Solaris, ça fonctionne parfaitement.
Sous NetBSD 4.0, le signal SIGSTART est bien envoyé au processus
fils (avec le bon PID, j'ai vérifié), kill() renvoie 0 donc ça se
passe bien. Mais le sigpending ne voit rien passer :
Pourtant, si j'en crois la page man du BSD en question :
The sigpending function returns a mask of the signals pending for deliv-
ery to the calling process in the location indicated by set. Signals may
be pending because they are currently masked, or they are in transition
before delivery (although the latter case is not normally detectable).
Donc si le signal est bloqué, il doit bien finir par arriver dans la
queue en question.
Bug de NetBSD ou ai-je raté quelque chose ?
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Ça a l'air un peu compliqué comme ça... En fait, c'est assez simple. Pour synchroniser le processus fils avec le processus père, j'envoie un signal SIGSTART (en fait SIGUSR2) vers le processus fils qui boucle sur un sigpending (le signal SIGSTART a été bloqué au préalable).
Problème : sous Linux et Solaris, ça fonctionne parfaitement. Sous NetBSD 4.0, le signal SIGSTART est bien envoyé au processus fils (avec le bon PID, j'ai vérifié), kill() renvoie 0 donc ça se passe bien. Mais le sigpending ne voit rien passer :
Pourtant, si j'en crois la page man du BSD en question :
The sigpending function returns a mask of the signals pending for deliv- ery to the calling process in the location indicated by set. Signals may be pending because they are currently masked, or they are in transition before delivery (although the latter case is not normally detectable).
Donc si le signal est bloqué, il doit bien finir par arriver dans la queue en question.
Bug de NetBSD ou ai-je raté quelque chose ?
Bon, je viens de googliser encore un peu. Visiblement sous NetBSD 3.1, la fonction renvoie toujours 0. Pratique. Je n'ai pas trouvé d'information concernant NetBSD 4.0. Ce qui est bizarre, c'est que je ne trouve aucune mention de fonction sigpending dans la libc, sauf en compat (en assembleur, et là, je sèche un peu).
JKB (en arch sparc)
PS : XP et fu2
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 15-04-2008, à propos de
sigpending() : fonctionnement différents entre Linux, NetBSD et Solaris ?,
JKB écrivait dans fr.comp.os.unix :
Bonjour à tous,
Toujours avec mes problèmes de gestions de signaux... Considérons le
bout de code suivant :
if (sigemptyset(&set) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}
Ça a l'air un peu compliqué comme ça... En fait, c'est assez simple.
Pour synchroniser le processus fils avec le processus père, j'envoie
un signal SIGSTART (en fait SIGUSR2) vers le processus fils qui
boucle sur un sigpending (le signal SIGSTART a été bloqué au
préalable).
Problème : sous Linux et Solaris, ça fonctionne parfaitement.
Sous NetBSD 4.0, le signal SIGSTART est bien envoyé au processus
fils (avec le bon PID, j'ai vérifié), kill() renvoie 0 donc ça se
passe bien. Mais le sigpending ne voit rien passer :
Pourtant, si j'en crois la page man du BSD en question :
The sigpending function returns a mask of the signals pending for deliv-
ery to the calling process in the location indicated by set. Signals may
be pending because they are currently masked, or they are in transition
before delivery (although the latter case is not normally detectable).
Donc si le signal est bloqué, il doit bien finir par arriver dans la
queue en question.
Bug de NetBSD ou ai-je raté quelque chose ?
Bon, je viens de googliser encore un peu. Visiblement sous NetBSD
3.1, la fonction renvoie toujours 0. Pratique. Je n'ai pas trouvé
d'information concernant NetBSD 4.0. Ce qui est bizarre, c'est que
je ne trouve aucune mention de fonction sigpending dans la libc,
sauf en compat (en assembleur, et là, je sèche un peu).
JKB (en arch sparc)
PS : XP et fu2
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Ça a l'air un peu compliqué comme ça... En fait, c'est assez simple. Pour synchroniser le processus fils avec le processus père, j'envoie un signal SIGSTART (en fait SIGUSR2) vers le processus fils qui boucle sur un sigpending (le signal SIGSTART a été bloqué au préalable).
Problème : sous Linux et Solaris, ça fonctionne parfaitement. Sous NetBSD 4.0, le signal SIGSTART est bien envoyé au processus fils (avec le bon PID, j'ai vérifié), kill() renvoie 0 donc ça se passe bien. Mais le sigpending ne voit rien passer :
Pourtant, si j'en crois la page man du BSD en question :
The sigpending function returns a mask of the signals pending for deliv- ery to the calling process in the location indicated by set. Signals may be pending because they are currently masked, or they are in transition before delivery (although the latter case is not normally detectable).
Donc si le signal est bloqué, il doit bien finir par arriver dans la queue en question.
Bug de NetBSD ou ai-je raté quelque chose ?
Bon, je viens de googliser encore un peu. Visiblement sous NetBSD 3.1, la fonction renvoie toujours 0. Pratique. Je n'ai pas trouvé d'information concernant NetBSD 4.0. Ce qui est bizarre, c'est que je ne trouve aucune mention de fonction sigpending dans la libc, sauf en compat (en assembleur, et là, je sèche un peu).
JKB (en arch sparc)
PS : XP et fu2
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Miod Vallat
Bon, je viens de googliser encore un peu. Visiblement sous NetBSD 3.1, la fonction renvoie toujours 0. Pratique. Je n'ai pas trouvé d'information concernant NetBSD 4.0. Ce qui est bizarre, c'est que je ne trouve aucune mention de fonction sigpending dans la libc, sauf en compat (en assembleur, et là, je sèche un peu).
sigpending est un appel système (compat_13_sys_sigpending chez NetBSD), la libc construit un .s à la volée lors de sa compilation.
Le fait de retourner zéro me paraît normal, et est conforme à Single Unix ; c'est à l'utilisateur ensuite de consulter la valeur ayant été mise à jour à l'adresse passée en paramètre.
Bon, je viens de googliser encore un peu. Visiblement sous NetBSD
3.1, la fonction renvoie toujours 0. Pratique. Je n'ai pas trouvé
d'information concernant NetBSD 4.0. Ce qui est bizarre, c'est que
je ne trouve aucune mention de fonction sigpending dans la libc,
sauf en compat (en assembleur, et là, je sèche un peu).
sigpending est un appel système (compat_13_sys_sigpending chez NetBSD),
la libc construit un .s à la volée lors de sa compilation.
Le fait de retourner zéro me paraît normal, et est conforme à Single
Unix ; c'est à l'utilisateur ensuite de consulter la valeur ayant été
mise à jour à l'adresse passée en paramètre.
Bon, je viens de googliser encore un peu. Visiblement sous NetBSD 3.1, la fonction renvoie toujours 0. Pratique. Je n'ai pas trouvé d'information concernant NetBSD 4.0. Ce qui est bizarre, c'est que je ne trouve aucune mention de fonction sigpending dans la libc, sauf en compat (en assembleur, et là, je sèche un peu).
sigpending est un appel système (compat_13_sys_sigpending chez NetBSD), la libc construit un .s à la volée lors de sa compilation.
Le fait de retourner zéro me paraît normal, et est conforme à Single Unix ; c'est à l'utilisateur ensuite de consulter la valeur ayant été mise à jour à l'adresse passée en paramètre.
JKB
Le 21-04-2008, à propos de Re: sigpending() : fonctionnement différents entre Linux, NetBSD et Solaris ?, Miod Vallat écrivait dans fr.comp.os.bsd :
Bon, je viens de googliser encore un peu. Visiblement sous NetBSD 3.1, la fonction renvoie toujours 0. Pratique. Je n'ai pas trouvé d'information concernant NetBSD 4.0. Ce qui est bizarre, c'est que je ne trouve aucune mention de fonction sigpending dans la libc, sauf en compat (en assembleur, et là, je sèche un peu).
sigpending est un appel système (compat_13_sys_sigpending chez NetBSD), la libc construit un .s à la volée lors de sa compilation.
Le fait de retourner zéro me paraît normal, et est conforme à Single Unix ; c'est à l'utilisateur ensuite de consulter la valeur ayant été mise à jour à l'adresse passée en paramètre.
On est bien d'accord. Le problème, c'est que cette valeur n'est _jamais_ mise à jour chez moi (je parle bien de la valeur passée par pointeur) quel que soit le signal bloqué reçu. J'ai eu confirmation par quelqu'un sur la liste NetBSD qui n'a lui non plus jamais réussi à faire fonctionner sigpending().
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 21-04-2008, à propos de
Re: sigpending() : fonctionnement différents entre Linux, NetBSD et Solaris ?,
Miod Vallat écrivait dans fr.comp.os.bsd :
Bon, je viens de googliser encore un peu. Visiblement sous NetBSD
3.1, la fonction renvoie toujours 0. Pratique. Je n'ai pas trouvé
d'information concernant NetBSD 4.0. Ce qui est bizarre, c'est que
je ne trouve aucune mention de fonction sigpending dans la libc,
sauf en compat (en assembleur, et là, je sèche un peu).
sigpending est un appel système (compat_13_sys_sigpending chez NetBSD),
la libc construit un .s à la volée lors de sa compilation.
Le fait de retourner zéro me paraît normal, et est conforme à Single
Unix ; c'est à l'utilisateur ensuite de consulter la valeur ayant été
mise à jour à l'adresse passée en paramètre.
On est bien d'accord. Le problème, c'est que cette valeur n'est
_jamais_ mise à jour chez moi (je parle bien de la valeur passée par
pointeur) quel que soit le signal bloqué reçu. J'ai eu confirmation
par quelqu'un sur la liste NetBSD qui n'a lui non plus jamais réussi
à faire fonctionner sigpending().
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 21-04-2008, à propos de Re: sigpending() : fonctionnement différents entre Linux, NetBSD et Solaris ?, Miod Vallat écrivait dans fr.comp.os.bsd :
Bon, je viens de googliser encore un peu. Visiblement sous NetBSD 3.1, la fonction renvoie toujours 0. Pratique. Je n'ai pas trouvé d'information concernant NetBSD 4.0. Ce qui est bizarre, c'est que je ne trouve aucune mention de fonction sigpending dans la libc, sauf en compat (en assembleur, et là, je sèche un peu).
sigpending est un appel système (compat_13_sys_sigpending chez NetBSD), la libc construit un .s à la volée lors de sa compilation.
Le fait de retourner zéro me paraît normal, et est conforme à Single Unix ; c'est à l'utilisateur ensuite de consulter la valeur ayant été mise à jour à l'adresse passée en paramètre.
On est bien d'accord. Le problème, c'est que cette valeur n'est _jamais_ mise à jour chez moi (je parle bien de la valeur passée par pointeur) quel que soit le signal bloqué reçu. J'ai eu confirmation par quelqu'un sur la liste NetBSD qui n'a lui non plus jamais réussi à faire fonctionner sigpending().
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.