From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3293 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Proposed new cancellation type Date: Tue, 7 May 2013 20:57:29 -0400 Message-ID: <20130508005729.GA17495@brightrain.aerifal.cx> 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 1367974665 12725 80.91.229.3 (8 May 2013 00:57:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 May 2013 00:57:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3297-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 08 02:57:46 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 1UZshU-0003CM-N8 for gllmg-musl@plane.gmane.org; Wed, 08 May 2013 02:57:44 +0200 Original-Received: (qmail 1389 invoked by uid 550); 8 May 2013 00:57:43 -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 1377 invoked from network); 8 May 2013 00:57:42 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3293 Archived-At: 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