Eugene V. Lyubimkin wrote:
> Well, not quite a Cupt bug, but I worked around it anyway (see commit
> 21c589bc).
Oh, yagh. glibc can't work around it because it doesn't know which
signal caused the interruption.
POSIX (XSH 2.4.4, Signal Effects on Other Functions) sayeth:
If the action of the signal is to terminate the process, the process
shall be terminated and the function shall not return. If the action
of the signal is to stop the process, the process shall stop until
continued or terminated. Generation of a SIGCONT signal for the
process shall cause the process to be continued, and the original
function shall continue at the point the process was stopped. If the
action of the signal is to invoke a signal-catching function, the
signal-catching function shall be invoked; in this case the original
function is said to be "interrupted" by the signal.
In Linux on x86, the signal handling codepath begins with
do_notify_resume ->
do_signal ->
get_signal_to_deliver
By default, SIGSTOP waits for receipt of SIGCONT and returns 0 from
get_signal_to_deliver. So restartable system calls gets restarted
with no chance of restart, by moving back the instruction pointer for
the function call back a little (and switching to sys_restart_syscall
in the case of system calls that return -ERESTART_RESTARTBLOCK to
request a little cleanup, like adjusting a timeout).
So goes the theory. The practice is sadly messier --- from
include/net/sock.h:
/* Alas, with timeout socket operations are not restartable.
* Compare this to poll().
*/
static inline int sock_intr_errno(long timeo)
{
return timeo == MAX_SCHEDULE_TIMEOUT ? -ERESTARTSYS : -EINTR;
}
So, "all" a person would need to do is add support for resuming to
sys_restart_syscall and change the above -EINTR to
-ERESTART_RESTARTBLOCK.
Probably the above should be a wishlist bug against the linux-2.6
package.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
