This is the mail archive of the
mailing list for the glibc project.
Re: [RFC] mutex destruction (#13690): problem description and workarounds
- From: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Thu, 04 Dec 2014 19:58:32 +0100
- 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> <20141204174233 dot GR4574 at brightrain dot aerifal dot cx>
On Thu, 2014-12-04 at 12:42 -0500, Rich Felker wrote:
> 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.
Either we're talking past each other or we're strongly disagreeing here.
IMO, an error condition is something I'm expected to handle --
especially if it is not part of a catch-all category like "errors 12 to
23 are all just nuances of the same problem". Before the new error
condition is added, how should callers know whether the new error will
be catastrophic, benign, not an error at all but a hint, or whatever?
> > > 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).
If the function is specified in a certain way, included the fixed set of
return values, then to add something transparently, it must fit within
those semantics. If you can't hide it in there, and need a new
category, it's not transparent from my point of view.