[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 30 Oct 2020 23:31:17 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH v2] MT fork
On Fri, Oct 30, 2020 at 03:31:54PM -0600, Ariadne Conill wrote:
> Hello,
>
> On Friday, October 30, 2020 12:57:17 PM MDT Rich Felker wrote:
> > There was a regression in musl too, I think. With
> > 27b2fc9d6db956359727a66c262f1e69995660aa you should be able to
> > re-enable parallel mark. If you get a chance to test, let us know if
> > it works for you.
>
> I have pushed current musl git plus the MT fork patch to Alpine edge as Alpine
> musl 1.2.2_pre0, and reenabling parallel mark has worked fine.
>
> It would be nice to have a musl 1.2.2 release that I can use for the source
> tarball instead of a git snapshot, but this will do for now.
Thanks for the feedback. I'll try to wrap up this release cycle pretty
quickly now, since I know this has been a big stress for distros, but
I want to make sure the MT-fork doesn't introduce other breakage.
One thing I know is potentially problematic is interaction with malloc
replacement -- locking of any of the subsystems locked at fork time
necessarily takes place after application atfork handlers, so if the
malloc replacement registers atfork handlers (as many do), it could
deadlock. I'm exploring whether malloc use in these systems can be
eliminated. A few are almost-surely better just using direct mmap
anyway, but for some it's borderline. I'll have a better idea sometime
in the next few days.
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.
