[RFC] mutex destruction (#13690): problem description and workarounds

[Carlos O'Donell]

On 12/01/2014 04:22 PM, Rich Felker wrote:
>> But how would you distinguish from "other spurious wakeups" that are
>> currently allowed?
> 
> As far as I can tell that's just ***-covering by the man page with no
> basis in what the kernel actually does. If there are actually current
> situations under which it can produce EINTR without a signal, that's
> very bad. For instance sem_wait must return EINTR when actually
> interrupted by a non-SA_RESTART signal, but it's forbidden from
> returning EINTR if that didn't happen. Spurious EINTR from sem_wait in
> a program that's written not to use interrupting signals at all (and
> thus without code to handle them by restarting the call, or otherwise)
> would be serious breakage. So if the current implementation really is
> returning EINTR for reasons other than interruption-by-signal, it's a
> serious bug in sem_wait and I don't know how it can be fixed without
> fixing the bad kernel behavior.

I agree.

A user should be able to write sem_wait code and expect never to
be interrupted if only SA_RESTART signals are used.

Cheers,
Carlos.