From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7082 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Masked cancellation mode draft Date: Sun, 22 Feb 2015 18:51:47 +0100 Message-ID: <20150222175146.GV32724@port70.net> References: <20150222032453.GA14201@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 1424627526 24782 80.91.229.3 (22 Feb 2015 17:52:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Feb 2015 17:52:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7095-gllmg-musl=m.gmane.org@lists.openwall.com Sun Feb 22 18:52:06 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YPahK-0003Bb-3z for gllmg-musl@m.gmane.org; Sun, 22 Feb 2015 18:52:06 +0100 Original-Received: (qmail 19730 invoked by uid 550); 22 Feb 2015 17:52:03 -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 19682 invoked from network); 22 Feb 2015 17:51:59 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20150222032453.GA14201@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:7082 Archived-At: * Rich Felker [2015-02-21 22:24:53 -0500]: > When the cancellation state is set to MASKED, the first cancellation > point (other than close, which is special) called with cancellation > pending, or which has a cancellation request arrive while it's > blocking, returns with an error of ECANCELED, and sets the > cancellation state to DISABLE. > > Even code which was not specifically written to be cancellation-aware > is compatible with this behavior. As long as it is responding to > errors, it will see the error, but will have the full repertoire of > standard functions available to use while cleaning up and returning > after the error. If the error is ignored, cancellation will be > delayed, but the behavior is no worse than what could already happen > from ignoring errors. > so it works like a special signal that only acts at blocking calls since the thread is not forcefully killed, only notified about the cancellation, the cleanup mechanism is under the control of the programmer this seems like a relevant approach to c11 and c++11 which currently lack any way to safely cancel blocking threads the only difficulty i see is that posix has a lot of cancellation points (some of which are optional) so code that wants to be 'masked cancellation safe' should properly do the error handling at a lot of places (eg some stdio functions like printf maybe cancellation points and usually not checked for errors directly only in aggregate through ferror) if i understood correctly code that does not want to immediately act upon masked cancellation (only at specific calls) should reset the cancellation state with pthread_setcancelstate(PTHREAD_CANCEL_MASKED, 0) and then cancellation is deferred until the next cancellation point. another issue is that pthread_testcancel() has no return value so it cannot be used for non-blocking testing of masked cancel.