From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6742 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Fixing multithreaded set*id() AS-safety Date: Sat, 20 Dec 2014 14:24:20 -0500 Message-ID: <20141220192420.GF4574@brightrain.aerifal.cx> References: <20141220033918.GA3273@brightrain.aerifal.cx> <1419065296.29611.1.camel@inria.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 1419103482 15085 80.91.229.3 (20 Dec 2014 19:24:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Dec 2014 19:24:42 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6755-gllmg-musl=m.gmane.org@lists.openwall.com Sat Dec 20 20:24:35 2014 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 1Y2Pdj-0003JK-Lo for gllmg-musl@m.gmane.org; Sat, 20 Dec 2014 20:24:35 +0100 Original-Received: (qmail 7582 invoked by uid 550); 20 Dec 2014 19:24:33 -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 7574 invoked from network); 20 Dec 2014 19:24:33 -0000 Content-Disposition: inline In-Reply-To: <1419065296.29611.1.camel@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6742 Archived-At: On Sat, Dec 20, 2014 at 09:48:16AM +0100, Jens Gustedt wrote: > Hello > > Am Freitag, den 19.12.2014, 22:39 -0500 schrieb Rich Felker: > > Neither approach is really attractive. Strategy 1 feels less hackish > > and more elegant (it actually makes the pthread_create code more > > elegant than it is now by having fewer special cases), but the cost > > feels wasteful. Strategy 2 is ugly but has the ugliness isolated to > > synccall.c (the internals for set*id()) where it doesn't interact with > > other parts of the code in any significant way. > > > > Any opinions on which way we should go? I'll probably hold off to do > > any of this until the next release cycle (or maybe even later), but I > > want to go ahead and start thinking about and discussing it. > > I am much more in favor of version 2 or something equivalent, because > it keeps the complexity where it belongs. As our implementation is > currently, all changes to pthread_create would equally impact > thrd_create. I'm open to your view, but I don't think it follows from your reasoning. Strategy 1 does not really add complexity to pthread_create. It makes fewer special cases in pthread_create I think. In effect what it's doing is just making the method of blocking thread creation AS-safe. Strategy 2 does add some code to pthread_create, but it just looks like: if (libc.block_new_threads) __wait(&libc.block_new_threads, 1, 1); or similar. This mechanism could also be used by dlopen to block new threads, freeing pthread_create from having to touch the __acquire_ptc lock it does now, but since this eliminates the ability for dlopen to wait for all threads to exit pthread_create, it would have to assume all threads are currently in pthread_create and might be about to create a new thread, and would thus have to pre-allocate twice the needed amount of TLS. I'm not sure that would be a good trade-off... Rich