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 09:51:41 -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> <20141203142837 dot GG4574 at brightrain dot aerifal dot cx> <1417703982 dot 22797 dot 21 dot camel at triegel dot csb>
On Thu, Dec 04, 2014 at 03:39:42PM +0100, Torvald Riegel wrote:
> > I have in mind an extension to the cancellation API that would address
> > this issue: a cancellation mode that causes the operation detecting
> > cancellation to return with ECANCELED rather than acting on
> > cancellation. I still have some details to work out on how it should
> > work in certain corner cases, but I'd like to implement it
> > experimentally for musl, and possibly propose it in the future for
> > glibc and for standardization in POSIX at some point, if there's
> > interest.
>
> The operations that can be cancelled in this new mode would have to
> opt-in, because their contract changes (new return value). Thus, you'd
For operations that have defined errors, POSIX permits additional
implementation-defined errors. This is not a change in contract. The
idea is that it would be safe to use this mode with any third-party
library code that properly checks for errors and treats any unknown
error as a condition that results in backing out any partial progress
and failing the current operation -- unlike the POSIX cancellation
model where it's impossible and dangerous to use cancellation with any
third-party library code not written specifically with cancellation in
mind.
> need to change the code in any case, or at the very least inspect it.
> But if you can do that, you can as well implement it with what we have
> already: just do a sem_post (or enough of them), for example. Or use a
> condvar. There's no fundamental building block missing.
I don't think you understand the problem domain this is intended to
solve. Semaphores are unrelated. The problem is blocking syscalls that
have nothing to do with synchronization, possibly embedded deep in
library code you can't or don't want to modify, where the application
needs a way to cancel an operation for which it no longer cares about
the result (e.g. a network connection that's taking too long to
respond).
> IMO, such features are better implemented in libraries on top of POSIX.
> Or, if it seems sufficiently widely used, at least in ISO C or ISO C++.
It cannot be implemented on top of POSIX. The only way to implement
such a thing is internal to the syscall cancellation mechanism. You
could implement it outside of libc in a third-party library, but doing
so would require special syscall asm for each arch for exactly the
same reasons that necessitate the cancellation redesign.
Rich