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

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).

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.