This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] mutex destruction (#13690): problem description and workarounds
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at libc dot org>, Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Tue, 02 Dec 2014 14:38:54 -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>
On 12/01/2014 04:22 PM, Rich Felker wrote:
>> But how would you distinguish from "other spurious wakeups" that are
>> currently allowed?
> 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. Spurious EINTR from sem_wait in
> a program that's written not to use interrupting signals at all (and
> thus without code to handle them by restarting the call, or otherwise)
> would be serious breakage. So if the current implementation really is
> returning EINTR for reasons other than interruption-by-signal, it's a
> serious bug in sem_wait and I don't know how it can be fixed without
> fixing the bad kernel behavior.
A user should be able to write sem_wait code and expect never to
be interrupted if only SA_RESTART signals are used.