Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190214231936.GX23599@brightrain.aerifal.cx>
Date: Thu, 14 Feb 2019 18:19:36 -0500
From: Rich Felker <dalias@...c.org>
To: Alexey Izbyshev <izbyshev@...ras.ru>
Cc: musl@...ts.openwall.com
Subject: Re: Draft outline of thread-list design

On Thu, Feb 14, 2019 at 05:32:24PM -0500, Rich Felker wrote:
> On Fri, Feb 15, 2019 at 12:16:39AM +0300, Alexey Izbyshev wrote:
> > In general, to my limited expertise, the design looks simple and
> > clean. I'm not sure whether it's worth optimizing to reduce
> > serialization pressure on pthread_create()/pthread_exit() because
> > creating a large amount of short-lived threads doesn't look like a
> > good idea anyway.
> 
> Yes. One thing I did notice is that the window where pthread_create
> has to hold a lock to prevent new dlopen from happening is a lot
> larger than the window where the thread list needs to be locked, and
> contains mmap/mprotect. I think we should add a new "DTLS lock" here
> that's held for the whole time, with a protocol that if you need both
> the DTLS lock and the thread list lock, you take them in that order
> (dlopen would also need them both). This reduces the thread list lock
> window to just the __clone call and list update.

Also: the DTLS lock function can have a weak dummy, so that
static-linked programs don't even perform any locking.

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.