From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5752 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: PATCH: don't call cleanup handlers after a regular return from the thread start function Date: Wed, 6 Aug 2014 06:12:54 -0400 Message-ID: <20140806101254.GW1674@brightrain.aerifal.cx> References: <20140805170942.GG1674@brightrain.aerifal.cx> <1407265576.24324.248.camel@eris.loria.fr> <20140805194117.GI1674@brightrain.aerifal.cx> <1407272741.24324.256.camel@eris.loria.fr> <20140805214827.GO1674@brightrain.aerifal.cx> <1407280798.24324.262.camel@eris.loria.fr> <20140806020254.GP1674@brightrain.aerifal.cx> <1407309326.24324.274.camel@eris.loria.fr> <20140806093529.GT1674@brightrain.aerifal.cx> <1407319247.24324.284.camel@eris.loria.fr> 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 1407320001 16621 80.91.229.3 (6 Aug 2014 10:13:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Aug 2014 10:13:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5757-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 06 12:13:15 2014 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 1XEyDT-0007Eq-F3 for gllmg-musl@plane.gmane.org; Wed, 06 Aug 2014 12:13:07 +0200 Original-Received: (qmail 22046 invoked by uid 550); 6 Aug 2014 10:13:06 -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 22038 invoked from network); 6 Aug 2014 10:13:06 -0000 Content-Disposition: inline In-Reply-To: <1407319247.24324.284.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5752 Archived-At: On Wed, Aug 06, 2014 at 12:00:47PM +0200, Jens Gustedt wrote: > Am Mittwoch, den 06.08.2014, 05:35 -0400 schrieb Rich Felker: > > BTW one "safety" we currently have is that pthread_cleanup_pop does > > not just "pop one cleanup context"; it resets the context to the one > > that was in effect at the time the corresponding push was called, > > potentially popping multiple contexts if one or more pop was skipped > > via illegal returns or similar. In principle a check-and-crash could > > be added asserting that self->cancelbuf == cb before doing this, but > > I'm mildly hesitant to add conditionals to something that should be a > > fast-path. > > You would have my +1 for that. Everyone should be aware that cleanup > push/pop comes with a cost and one conditional jump really doesn't add > much to the cost. Indeed. And it should be a 100% predictable jump. My main concern then is whether we can ensure that it doesn't have false-positives (crashes for valid-but-ugly usage). > > One "safe" approach might be for call_once to simply block > > cancellation for the duration of the call. In fact C11 threads could > > even start with cancellation blocked, unless of course POSIX mandates > > otherwise in the next issue. > > right, good idea, I'll give it a thought The latter probably doesn't help, since obviously the main thread can't start with cancellation disabled, and call_once is likely to be called from a thread started with pthread_create in applications where the C11 thread code is just in a thread-safe library that doesn't itself make the threads that are doing the calling. On the other hand, having call_once block cancellation should eliminate the problem, but there's a chance POSIX would not allow that behavior. We should really make a summary of the issues that have come up in this thread to deliver for consideration when the Austin Group works on aligning POSIX with C11. There's a much better chance that they'll avoid specifying things that would be problematic if there's documented discussion of the issues that arise. Rich