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: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Tue, 2 Dec 2014 16:03:16 -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>
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.
> 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.
Rich