This is the mail archive of the
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 12:42:34 -0500
- Subject: Re: [RFC] mutex destruction (#13690): problem description and workarounds
- Authentication-results: sourceware.org; auth=none
- References: <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> <20141204145141 dot GO4574 at brightrain dot aerifal dot cx> <1417710165 dot 22797 dot 28 dot camel at triegel dot csb>
On Thu, Dec 04, 2014 at 05:22:45PM +0100, Torvald Riegel wrote:
> On Thu, 2014-12-04 at 09:51 -0500, Rich Felker wrote:
> > 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
> This last part is not required by the current operations, so it would be
> new, right? And thus not equal to the old contract anymore...
No. We're talking about operations that could already fail with
reasons like EPIPE, ECONNRESET, EIO, etc. Adding a new reason to fail
to an interface that already has reasons it can fail under correct
usage is not a change to the contract.
> > 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).
> I doubt there's a cancellation mechanism that works transparently in the
> general case. I agree there might be mechanism that work for certain
> cases and after code inspection. But that sounds like more of a corner
> case for me.
"Transparently" is not clearly defined, but I think for code that's
handling error returns correctly already, you'd get the desired
behavior, and you would never risk dangerously-wrong misbehavior (like
what you get applying cleanup-handler-based cancellation to code not
written to support it).
> > > 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.
> Well, why not use nonblocking IO then?
In some cases this works -- it depends on the blocking operation in
question being a fd wait, in which case you can also just add a
"cancel pipe" to the poll set and write to it to cancel. However this
requires significant redesign and API changes to add into existing
libraries. The functionality I'm talking about would make it safe to
cancel threads blocked in things like SSL_read, deflate, libavformat
demuxers, ... simply by utilizing their existing error paths for
In any case we can see whether it makes sense and achieves the desired
goals once I have something to demo.