[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 May 2013 20:57:29 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Proposed new cancellation type
Hi,
I've mentioned on IRC a few times before the idea of adding a new
thread cancellation type in musl, whereby, rather than calling cleanup
handlers and exiting when acting on cancellation at a cancellation
point, the function which is a cancellation point would instead fail
with ECANCELED. This would allow cancellation to be used in idiomatic
C code, without the ugly exception-handling-like coding style, and
would allow well-defined interaction of cancellation and C++. The idea
of implementing such a feature despite it not being standard or having
any prior art is that (1) it's super easy to do, and would simplify a
lot of internal code in musl, and (2) it would be a basis (existing
implementation) for proposing it for inclusion in POSIX (it should be
just as easy to add to other implementations, i.e. not a big
implementation burden).
A few questions:
1. With normal cancellation, when the cancellation request is acted
on, cancellation is disabled, so that further calls to cancellation
points in the cleanup handlers don't in turn get cancelled. Would
it make sense for only the _first_ cancellation point called to
fail with ECANCELED (and after that, for cancellation to remain
disabled)? Or should all fail until it's explicitly disabled?
2. Should this new mode be a cancellation state (presently only
ENABLED or DISABLED) or a type (presently only ASYNCHRONOUS or
DEFERRED). I'm leaning towards the latter because async and this
new mode appear mutually exclusive.
The benefits:
1. Cancellation can be enabled even while calling library code that
was not intended for use with cancellation, as long as that library
code checks for error return values and properly backs out and
returns.
2. Cancellation can be used with C++ without horrible UB.
3. Cancellation can be used with natural, idiomatic C (checking error
returns) rather than exception-handling style.
4. Data needed for cleanup handlers does not need to be encapsulated
into structures to pass to the cleanup handler; the caller's local
variables are directly accessible for cleanup in the error case.
Does anybody else have input on how this feature should work, or
possible problems I might not have thought of?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
