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: Torvald Riegel <triegel 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 10:40:45 -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 12/04/2014 09:32 AM, Torvald Riegel wrote:
>> 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.
If we are going to disallow a signal to interrupt sem_post we should just
change the semantics, version the interface, and document that glibc no
longer ever returns EINTR for sem_wait, and that the right way to interrupt
it is with a signal handler that does sem_post.
This prevents users from complaining that what they observe with strace
and gdb is a signal arriving after the sem_wait, but not interrupting it.
We can claim the user is looking under the hood, but that's what they do,
and if we can possibly avoid those arguments we win. We know we're right,
we know we don't want to allow timing to imply ordering, but we need time
to educate developers (and that looking under the hood leads to non-obvious
I really wish the kernel returned some other error code for woken up
vs. signal. Is it not possible to get the kernel to distinguish these
two? Am I forgetting something?
> 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.