[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141220192420.GF4574@brightrain.aerifal.cx>
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.
