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

[Carlos O'Donell]

On 12/02/2014 04:03 PM, Rich Felker wrote:
> On Tue, Dec 02, 2014 at 09:45:18PM +0100, Torvald Riegel wrote:
>>> 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.
> 
> Indeed, I had missed this. It seems preferable that an implementation
> not act on such interruptions, and at least this choice allows an
> "out" if the kernel has the broken behavior of spurious EINTRs, but I
> still think it's better for the kernel never to return EINTR except
> for genuine interruption-by-signal.

I agree. The conflation of EINTR for non-signal use is IMO going to be
a design decision we regret in the future.
 
>> The signal man pages list sem_wait as having to return EINTR if
>> interrupted, but what's the point?
> 
> This applies to all uses of interrupting signal handlers, which is why
> I personally think they should be deprecated. However, you can work
> around the issue by repeating the signal with exponential backoff
> until the thread sending the signal can determine that the target
> thread has acted upon the interruption.

Or avoid relying on EINTR and cancel the thread?

Cheers,
Carlos.