Re: Strange Linux behaviour with blocking syscalls and stop signals+SIGCONT

[Ulrich Drepper <drepper@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

Michael Kerrisk wrote:
>> Whoa, not so fast.  At least the futex syscall but be interruptible by
>> signals.  It is crucial to return EINTR.
> 
> When you say "return" do you mean "in kernel", or "return 
> to userspace"?  My (possibly naive) understanding is that
> one could simply s/EINTR/ERESTARTNOHAND/ for FUTEX_WAIT, in
> order to achieve the change I want: for userland that 
> ERESTARTNOHAND would be returned as EINTR if a signal 
> handler interrupted the FUTEX_WAIT.

The futex syscall must _at least_ behave like every other syscall which
can block and can be interrupted by a signal.  It essential for internal
operation (cancellation) but also for programs.  For the former any
change which still allows EINTR to be reported could be acceptable.  We
install the signal handler internally and so make sure it's correct.

sem_wait() is another case.  Here the EINTR handling is exposed to the
programmer.  Currently, as I understand it, even SA_RESTART handlers
cause EINTR to be returned.  Yes, this usually correct but it  might
disrupt existing code.

This is why I'd caution anybody who thinks about changing something in
this area.  *I* could live with it, I can fix and recompile all the code
I use.  But others aren't that lucky.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]