> > Hmm...This works properly on libc5 systems, btw. (glibc2.0 and glibc2.1
> > use nanosleep(), libc5 uses alarm() and sigsuspend()).
> >
>
> It really could be argued what is the right behaviour here. When a
> system call is interrupted by the signal, the normal thing is to
> return EINTR.
>
I think I did not explained the problem clearly:
My reading of the The POSIX philosophy is that it is not legal for a
blocking system call to return EINTR when it has been interrupted by a
signal that does not have a signal handler attached to it at the time
the signal has been delivered to the process.
The behaviour of the Linux kernel for that is that it always returns
EINTR when a blocking system call has been interrupted by a signal,
whether there was a signal handler attached *OR NOT*. THIS IS THE
REASON WHY I STATED THAT LINUX IS NOT POSIX-COMPLIANT ON THIS SPECIAL
SIGNAL MANAGEMENT.
I gave the example of sleep because this was a very simple one that
everybody can exercise with bash. BUT THIS IS IMHO A MORE GENERAL PROBLEM.
Notice that this has only to deal with signals which effect is to start/stop
the process. The management of other signals is perfectly POSIX-compliant.
IMHO, the SIGSTOP management (which is much simpler than the others since
the signal can never be ignored nor caught) should be taken into account
in the schedule loop, and not in the signal management on syscall return.
Notice that SIGTSTP, SIGTTIN and SIGTTOU should be handled at the same
place when the default signal behaviour is applied, as well as some other
special cases like ignored SIGCHLD,... Part of this code is currently in
machine-dependent do_signal() function.
The advantage of such modification is that a blocking system call will
remain in the actual schedule loop whenever SIGSTOP/SIGTSTP and SIGCONT
are sent to him (thus eliminating the EINTR problem, and being POSIX
compatible). The other advantage is that for a traced process, the SIGSTOP
handling may also be managed in the schedule loop, thus avoiding the side
effect of being awaken by PTRACE_ATTACH/PTRACE_CONTINUE.
*BUT*, the schedule loop should only be managed by knowledgable people.
And I let them see the problem and what could be the actual fix...
-Eric
BTW, notice that the SA_RESTART is *NOT* the right solution, since it is
only handled when a signal handler has been attached. If no signal
handler is attached (which is the default behaviour), then this
solution does not work.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE
Web : http://www.ri.silicomp.com/~paire | Group SILICOMP - Research Institute
Email: eric.paire@ri.silicomp.com | 2, avenue de Vignate
Phone: +33 (0) 476 63 48 71 | F-38610 Gieres
Fax : +33 (0) 476 51 05 32 | FRANCE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/