This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Thu, Dec 04, 2014 at 03:32:13PM +0100, Torvald Riegel wrote:
> On Wed, 2014-12-03 at 09:02 -0500, Carlos O'Donell wrote:
> > 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.
> I'd rather see the fault in POSIX semantics, and it not making it clear
> that signal handlers should do sem_post if they need to reliably
> interrupt a sem_wait.
> Allowing spurious wake-ups in futex_wait anywhere is not a bad thing --
> remember that this works just fine in condvars, and nobody is
> complaining about that.  The issue is trying to merge in things like
> signals without a proper synchronization scheme backing that up.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]