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 17:15:08 -0500
- Subject: Re: [RFC] mutex destruction (#13690): problem description and workarounds
- Authentication-results: sourceware.org; auth=none
- References: <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> <20141204145452 dot GP4574 at brightrain dot aerifal dot cx>
On Thu, Dec 04, 2014 at 09:54:52AM -0500, Rich Felker wrote:
> 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.
I came across another function whose blocking-wait backend is most
easily implemented in terms of futex wait, and for which EINTR is a
mandatory error rather than an optional one: aio_suspend. If futex can
return EINTR spuriously, then aio_suspend would have to use an
alternate wait mechanism (pipe?) which would probably be significantly
more expensive.
Rich