Bug#159899: libc6: sem_wait is not interrupted by signals, as required by SuS

[Zack Weinberg <zack@codesourcery.com>]

Jack Howarth wrote:
>    Ulrich declines on this one for glibc 2.3. His reponse is...
> 
> -----------------------------------------------------------------------
> Did anybody actually read the standard?  The return after interrupt is a 
> 'may' error.  The implementation is correct.

I read the standard differently:

  DESCRIPTION 

    The sem_wait() function locks the semaphore referenced by
    sem by performing a semaphore lock operation on that semaphore.
    [...]

    The sem_wait() function is interruptible by the delivery of a
    signal.

  [http://www.opengroup.org/onlinepubs/007908799/xsh/sem_wait.html]

That last sentence doesn't give an implementor a choice: the function
is interruptible by signals.

Also, from a quality-of-implementation point of view, the current
behavior makes it easy to introduce meta-bugs of the form 'if this
deadlock condition happens, the user can't get out of the program 
with ^C' - quite frustrating during development.

And finally, a fix looks quite simple: in __new_sem_wait/
__old_sem_wait, when suspend() returns but the semaphore is
unavailable and the thread hasn't been cancelled, we currently
increment spurious_wakeup_count and loop.  Instead, set errno 
to EINTR and return failure.  (I don't understand all the nuances
of the pthreads implementation; it might not be that simple.)

In any case, please leave the bug open until it is fixed.

zw