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

[Rich Felker <dalias at libc dot org>]

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
read/write errors.

In any case we can see whether it makes sense and achieves the desired
goals once I have something to demo.

Rich