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.