Bonjour,

j'ai l'impression d'être tombé sur un bogue du noyau à propos de la fonction nanosleep(2). Le manuel (signal(7)) dit très clairement que la fonction nanosleep n'est jamais redémarrée après avoir été interrompu par un signal (ligne 494 de ma version du manuel). Mais j'observe le contraire (avec un noyau 2.6.24 sous ubuntu 9.04 et un noyau 2.6.31 sous ubuntu 9.10).

Le programme suivant :
http://repository.quare.fr/C/nanosleep.c
exécuté avec "strace ./a.out" affiche vers la fin de son exécution ces quatres lignes :

rt_sigaction(SIGALRM, {SIG_IGN}, {SIG_DFL}, 8) = 0
nanosleep({0, 300000000}, 0) = ? ERESTART_RESTARTBLOCK (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
restart_syscall(<... resuming interrupted call ...>) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0

Qui indiquent que l'appel a été redémarré. Est-ce que quelqu'un peut me confirmer si ça fait pareil sur d'autre plateforme ? Si c'est du à la libc et non pas au noyau ? si c'est vraiment un problème avec le noyau ? s'il y a un moyen de corriger ce comportement ?

Merci d'avance.

Je ne sais pas exactement ce que dit posix, mais le man de nanosleep dit :
"If the call is interrupted by a signal handler, nanosleep() returns -1"
En l'occurence dans ton code, le signal est ignore, cela ne fait donc pas d'appel a un signal handler. Si tu met un handler debile comme ici : http://pastebin.com/m78701886 alors le l'appel est interrompu comme le montre strace :
nanosleep({0, 300000000}, 0) = ? ERESTART_RESTARTBLOCK (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xe) = -1 EINTR (Interrupted system call)

Donc j'ai envie de dire que ce n'est pas un bug. Un bsdien peut tester ?

Pour reference:
$ uname -a
Linux powell 2.6.26-2-amd64 #1 SMP Fri Aug 14 07:12:04 UTC 2009 x86_64 GNU/Linux

J'ai mis la main sur un max.
meme comportement la bas.

Darwin 10.2.0

Le man dit :
" An unmasked signal will cause nanosleep() to terminate
the sleep early, regardless of the SA_RESTART value on the interrupting
signal."

Je pense vraiment que le comportement est normal. Mis jetter un oeil dans posix pourrait confirmer ca.

A d'accord, j'ai pensé que le comportement serait le même que le signal soit traité ou ignoré vu que dans tout les cas il interrompt l'appel système (j'ai du être induit en erreur par le fait que c'est la sémantique que le système avait auparavant manifestement).

En même temps, quand le process est ptracé (avec strace par exemple ici), je me serais aussi attendu à ce que l'appel soit interrompu.

En tout cas, merci pour tes info.