Date: Sat, 20 Dec 2014 14:24:20 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Fixing multithreaded set*id() AS-safety 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.