From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3298 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Proposed new cancellation type Date: Wed, 8 May 2013 15:17:04 -0400 Message-ID: <20130508191703.GE20323@brightrain.aerifal.cx> References: <20130508005729.GA17495@brightrain.aerifal.cx> <20130508085431.GC12689@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1368040645 30626 80.91.229.3 (8 May 2013 19:17:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 May 2013 19:17:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3302-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 08 21:17:21 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Ua9rZ-0001CM-RR for gllmg-musl@plane.gmane.org; Wed, 08 May 2013 21:17:17 +0200 Original-Received: (qmail 25660 invoked by uid 550); 8 May 2013 19:17:16 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25644 invoked from network); 8 May 2013 19:17:16 -0000 Content-Disposition: inline In-Reply-To: <20130508085431.GC12689@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3298 Archived-At: On Wed, May 08, 2013 at 10:54:31AM +0200, Szabolcs Nagy wrote: > * Rich Felker [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