This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]