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.