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

[Torvald Riegel <triegel at redhat dot com>]

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...

>  -- 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,

If this wouldn't affect the current synchronization mechanisms, I
wouldn't have a strong opinion against that anymore.

> 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.

> > 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?