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

["Carlos O'Donell" <carlos at redhat dot com>]

On 12/02/2014 03:45 PM, Torvald Riegel wrote:
>> I think this is incorrect documentation. I cannot find any hint at
>> what other sort of "other spurious wake-ups" could cause EINTR.
> 
> But that's no reason to not have it.  I think it makes perfect sense to
> allow for spurious wake-ups, especially for futexes.  Even if currently
> there's no case in which there would be a spurious wake-up, it's safer
> to have an error code that allows it so that if you need to have a
> spurious wake-up later on, you have a way to delegate the issue to the
> caller -- which, for futexes, is perfectly fine due to how they are
> designed.

What is the reason we want spurious wake-up allowed? Simply to make
the mutex destruction issue simpler to fix? I'd like to see a new thread
started with a clear description of what spurious wake-up buys the
implementation.

>>>> There are other ways to use interrupting signals similarly to
>>>> cancellation where you actually want to know you were interrupted by a
>>>> signal handler.
>>>
>>> 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.
> 
> EINTR is a 'may fail'.  POSIX states that sem_wait is interruptible, but
> I read this as allowing interruption, not requiring it.

Careful. The 'may fail' are implementation optional parts, and at present
glibc AFAIK fails only in the intended case which is for non-SA_RESTART
signals interrupting the futex and returning EINTR. By allowing a futex
to spuriously fail without a signal would break conforming uses of sem_wait. 

> The signal man pages list sem_wait as having to return EINTR if
> interrupted, but what's the point?  There's no way for the thread that
> raises the signal to know when sem_wait has started to execute.  So you
> can never be sure when a signal will actually hit sem_wait.  The only
> way I see to reliably interrupt sem_wait is to have the signal handler
> execute sem_post -- because that's the only thing sem_wait checks before
> blocking.  But then all that the semaphore implementation needs to do is
> try to lock the semaphore when interrupted, and in this case it won't
> return EINTR either.

Careful. The man pages are a terrible source of canonical documentation,
they simply list whatever anyone "discovers" about the interface, and not
the actual contract or intended interface.

I don't quite follow what you're trying to argue. Could you expand in
another thread with code examples?

Cheers,
Carlos.