* Proposed new cancellation type
@ 2013-05-08 0:57 Rich Felker
2013-05-08 7:35 ` Jens Gustedt
2013-05-08 8:54 ` Szabolcs Nagy
0 siblings, 2 replies; 5+ messages in thread
From: Rich Felker @ 2013-05-08 0:57 UTC (permalink / raw)
To: musl
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Proposed new cancellation type
2013-05-08 0:57 Proposed new cancellation type Rich Felker
@ 2013-05-08 7:35 ` Jens Gustedt
2013-05-08 18:07 ` Rich Felker
2013-05-08 8:54 ` Szabolcs Nagy
1 sibling, 1 reply; 5+ messages in thread
From: Jens Gustedt @ 2013-05-08 7:35 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
Rich,
I think it would be a good idea to think along these lines from a
different aspect, namely C11 / C++11 threads. For the moment they
don't include cancellation. Your ideas might be a good fit there,
too. Something simple that would easily integrate into the error
handling facilities of both languages.
In any case, since threads now are considered part of the programming
languages, any proposal in that direction should have their evolution
in mind, too.
Jens
--
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090 ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536 ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183 ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Proposed new cancellation type
2013-05-08 0:57 Proposed new cancellation type Rich Felker
2013-05-08 7:35 ` Jens Gustedt
@ 2013-05-08 8:54 ` Szabolcs Nagy
2013-05-08 19:17 ` Rich Felker
1 sibling, 1 reply; 5+ messages in thread
From: Szabolcs Nagy @ 2013-05-08 8:54 UTC (permalink / raw)
To: musl
* Rich Felker <dalias@aerifal.cx> [2013-05-07 20:57:29 -0400]:
>
> 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?
>
i think libraries should be prepared for this
ECANCELLED either way
- first only strategy:
eg in fflush(0) several blocking syscalls
are made in a loop, it should return when
ECANCELLED is detected to avoid further
blocking
another issue is that the failure of some
cancellation points are not reported by
libraries: eg close is a cancellation point
but its failure is usually not treated as
an error so cancellation can be unnoticed
- cancel everything strategy:
libraries that try to act on errors
(eg log some error message) will
fail to do so, which can be bad if the
cleanup code of the library requires
blocking calls
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Proposed new cancellation type
2013-05-08 7:35 ` Jens Gustedt
@ 2013-05-08 18:07 ` Rich Felker
0 siblings, 0 replies; 5+ messages in thread
From: Rich Felker @ 2013-05-08 18:07 UTC (permalink / raw)
To: musl
On Wed, May 08, 2013 at 09:35:07AM +0200, Jens Gustedt wrote:
> Rich,
> I think it would be a good idea to think along these lines from a
> different aspect, namely C11 / C++11 threads. For the moment they
> don't include cancellation. Your ideas might be a good fit there,
> too. Something simple that would easily integrate into the error
> handling facilities of both languages.
>
> In any case, since threads now are considered part of the programming
> languages, any proposal in that direction should have their evolution
> in mind, too.
While I agree with your sentiment and would like to get something like
this in the language standards, I also think that's a much harder goal
to achieve. Their committees operate on much longer time frames and
are much stricter about what makes it in. My feeling is to focus on
POSIX first, but keep in mind ways the same ideas could be applied to
the language standards. In particular, applying this to C11 without
attaching the whole pthread cancellation cleanup framework would
probably require C11 threads to start with this new cancellation type,
rather than normal deferred cancellation, when implemented on top of
POSIX threads.
Rich
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Proposed new cancellation type
2013-05-08 8:54 ` Szabolcs Nagy
@ 2013-05-08 19:17 ` Rich Felker
0 siblings, 0 replies; 5+ messages in thread
From: Rich Felker @ 2013-05-08 19:17 UTC (permalink / raw)
To: musl
On Wed, May 08, 2013 at 10:54:31AM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@aerifal.cx> [2013-05-07 20:57:29 -0400]:
> >
> > 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?
> >
>
> i think libraries should be prepared for this
> ECANCELLED either way
>
> - first only strategy:
>
> eg in fflush(0) several blocking syscalls
> are made in a loop, it should return when
> ECANCELLED is detected to avoid further
> blocking
>
> another issue is that the failure of some
> cancellation points are not reported by
> libraries: eg close is a cancellation point
> but its failure is usually not treated as
> an error so cancellation can be unnoticed
This draws out the really ugly Linux close issue: Linux's handling of
interruption of close is non-conforming, in that the syscall returns
EINTR but with the file descriptor already closed. musl fixes this in
userspace, but it means (1) applications are unlikely to check for the
error in close, and (2) if close is interrupted by a cancellation
request, the side effects have already taken place, so cancellation
cannot be acted upon.
Cancellation _can_ however be acted upon in close before the syscall
is made. I feel this would be really problematic with the new proposed
cancellation type, so the correct approach might be to make a list of
functions (possibly only close) which ignore cancellation requests in
this mode.
Unfortunately this is getting more complicated and thereby harder to
propose for standardization. :(
> - cancel everything strategy:
>
> libraries that try to act on errors
> (eg log some error message) will
> fail to do so, which can be bad if the
> cleanup code of the library requires
> blocking calls
Not only that, they'll fail to back out progress since close will
fail. Even if we exempt close (as above), some library functions might
have to back out progress using functions that look like
forward-process functions (in this case, of course, they'll have ugly
unrecoverable failure cases anyway), so I think the "keep failing"
strategy is unlikely to work well in practice.
Rich
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-05-08 19:17 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-08 0:57 Proposed new cancellation type Rich Felker
2013-05-08 7:35 ` Jens Gustedt
2013-05-08 18:07 ` Rich Felker
2013-05-08 8:54 ` Szabolcs Nagy
2013-05-08 19:17 ` Rich Felker
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).