Re: [RFC] mutex destruction (#13690): problem description and workarounds

[Torvald Riegel <triegel at redhat dot com>]

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.