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

[Rich Felker]

On Thu, Dec 04, 2014 at 09:54:52AM -0500, Rich Felker wrote:
> I agree totally that spurious wakeups are not bad, but they must not
> overload an error code that has a defined meaning. EINTR is ONLY for
> interruption by signal. Even if you disagree with my arguments about
> sem_post (and you're wrong; POSIX *does* guarantee eventual forward
> progress), sem_post was just the best example that came to mind of a
> standard function that's affected. Overloading EINTR to mean anything
> but "interrupted by non-SA_RESTART signal" is a horrible horrible idea
> that will come back to haunt us if it's done. This should not even be
> on the table. It makes it impossible to implement any operation where
> EINTR is a mandatory error, rather than an optional one, and probably
> leads to others problems that I have not yet thought of too. Please,
> drop it.

I came across another function whose blocking-wait backend is most
easily implemented in terms of futex wait, and for which EINTR is a
mandatory error rather than an optional one: aio_suspend. If futex can
return EINTR spuriously, then aio_suspend would have to use an
alternate wait mechanism (pipe?) which would probably be significantly
more expensive.

Rich