[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130508191703.GE20323@brightrain.aerifal.cx>
Date: Wed, 8 May 2013 15:17:04 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Proposed new cancellation type
On Wed, May 08, 2013 at 10:54:31AM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...ifal.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
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.
