This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] mutex destruction (#13690): problem description and workarounds
- From: Rich Felker <dalias at libc dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Thu, 4 Dec 2014 09:54:52 -0500
- Subject: Re: [RFC] mutex destruction (#13690): problem description and workarounds
- Authentication-results: sourceware.org; auth=none
- References: <1396621230 dot 10643 dot 7191 dot camel at triegel dot csb> <20141201153802 dot GV29621 at brightrain dot aerifal dot cx> <1417452125 dot 1771 dot 503 dot camel at triegel dot csb> <20141201170542 dot GY29621 at brightrain dot aerifal dot cx> <1417467150 dot 1771 dot 581 dot camel at triegel dot csb> <20141201212223 dot GZ29621 at brightrain dot aerifal dot cx> <1417553118 dot 3930 dot 14 dot camel at triegel dot csb> <20141202210316 dot GI29621 at brightrain dot aerifal dot cx> <547F17E3 dot 9060901 at redhat dot com> <1417703533 dot 22797 dot 16 dot camel at triegel dot csb>
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.
Rich