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: Torvald Riegel <triegel at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Thu, 04 Dec 2014 15:32:13 +0100
- 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>
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.