sigpending() : fonctionnement différents entre Linux, NetBSD et Solaris ?

Le
JKB
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;
}

if (sigaddset(&set, SIGSTART) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}

/*
* Le signal SIGFSTOP doit être traité !
*/

if (sigaddset(&set, SIGFSTOP) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}

if (pthread_sigmask(SIG_BLOCK, &set, &oldset) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}



(*s_argument_thread).pid = fork();

if ((*s_argument_thread).pid > 0)
{
if (pthread_mutex_unlock(&mutex) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}

}
else
{

printf("3> %d", getpid());
if (sigpending(&set) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
}
else if (sigismember(&set, SIGSTART) == 0)
{
printf("3.1> %d", getpid());
while(sigismember(&set, SIGSTART) == 0)
{
printf("3.2>");
if (sigpending(&set) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
}

nanosleep(&attente, NULL);
}
}
printf("4>");

}

printf("P1> %d", (*s_argument_thread).pid);
if (kill((*s_argument_thread).pid, SIGSTART) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
pthread_mutex_unlock(&mutex);
return;
}
printf("P2>");

if (pthread_sigmask(SIG_SETMASK, &oldset, NULL) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
pthread_mutex_unlock(&mutex);
return;
}

sigpending(&set);
printf("P3>");

Ç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 :

1>
2>
3> 1703
3.1> 1703
3.2>
3.2>
P1> 1703
P2>
P3>
3.2>
P1> 19399
P2>
P3>
3.2>
3.2>
3.2>
3.2>
3.2>


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.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JKB
Le #3697411
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;
}

if (sigaddset(&set, SIGSTART) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}

/*
* Le signal SIGFSTOP doit être traité !
*/

if (sigaddset(&set, SIGFSTOP) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}

if (pthread_sigmask(SIG_BLOCK, &set, &oldset) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}

...

(*s_argument_thread).pid = fork();

if ((*s_argument_thread).pid > 0)
{
if (pthread_mutex_unlock(&mutex) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
return;
}
...
}
else
{
...
printf("3> %dn", getpid());
if (sigpending(&set) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
}
else if (sigismember(&set, SIGSTART) == 0)
{
printf("3.1> %dn", getpid());
while(sigismember(&set, SIGSTART) == 0)
{
printf("3.2>n");
if (sigpending(&set) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
}

nanosleep(&attente, NULL);
}
}
printf("4>n");
...
}

printf("P1> %dn", (*s_argument_thread).pid);
if (kill((*s_argument_thread).pid, SIGSTART) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
pthread_mutex_unlock(&mutex);
return;
}
printf("P2>n");

if (pthread_sigmask(SIG_SETMASK, &oldset, NULL) != 0)
{
(*s_etat_processus).erreur_systeme = d_es_processus;
pthread_mutex_unlock(&mutex);
return;
}

sigpending(&set);
printf("P3>n");

Ç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 :

1>
2>
3> 1703
3.1> 1703
3.2>
3.2>
P1> 1703
P2>
P3>
3.2>
P1> 19399
P2>
P3>
3.2>
3.2>
3.2>
3.2>
3.2>
...

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
Le #5925891
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 #6143041
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.


Publicité
Poster une réponse
Anonyme