[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201026005912.GJ534@brightrain.aerifal.cx>
Date: Sun, 25 Oct 2020 20:59:20 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Status report and MT fork
On Sun, Oct 25, 2020 at 08:50:29PM -0400, Rich Felker wrote:
> I just pushed a series of changes (up through 0b87551bdf) I've had
> queued for a while now, some of which had minor issues that I think
> have all been resolved now. They cover a range of bugs found in the
> process of reviewing the possibility of making fork provide a
> consistent execution environment for the child of a multithreaded
> parent, and a couple unrelated fixes.
>
> Based on distro experience with musl 1.2.1, I'm working on getting the
> improved fork into 1.2.2. Despite the fact that 1.2.1 did not break
> anything that wasn't already broken (apps invoking UB in MT-forked
> children), prior to it most of the active breakage was hit with very
> low probability, so there were a lot of packages people *thought* were
> working, that weren't, and feedback from distros seems to be that
> getting everything working as reliably as before (even if it was
> imperfect and dangerous before) is not tractable in any reasonable
> time frame. And in particular, I'm concerned about language runtimes
> like Ruby that seem to have a contract with applications they host to
> support MT-forked children. Fixing these is not a matter of fixing a
> finite set of bugs but fixing a contract, which is likely not
> tractable.
>
> Assuming it goes through, the change here will be far more complete
> than glibc's handling of MT-forked children, where most things other
> than malloc don't actually work, but fail sufficiently infrequently
> that they seem to work. While there are a lot of things I dislike
> about this path, one major thing I do like is that it really makes
> internal use of threads by library code (including third party libs)
> transparent to the application, rather than "transparent, until you
> use fork".
>
> Will follow up with draft patch for testing.
Patch attached. It should suffice for testing and review of whether
there are any locks/state I overlooked. It could possibly be made less
ugly too.
Note that this does not strictly conform to past and current POSIX
that specify fork as AS-safe. POSIX-future has removed fork from the
AS-safe list, and seems to have considered its original inclusion
erroneous due to pthread_atfork and existing implementation practice.
The patch as written takes care to skip all locking in single-threaded
parents, so it does not break AS-safety property in single-threaded
programs that may have made use of it. -Dfork=_Fork can also be used
to get an AS-safe fork, but it's not equivalent to old semantics;
_Fork does not run atfork handlers. It's also possible to static-link
an alternate fork implementation that provides its own pthread_atfork
and calls _Fork, if really needed for a particular application.
Feedback from distro folks would be very helpful -- does this fix all
the packages that 1.2.1 "broke"?
Rich
View attachment "mt-fork.diff" of type "text/plain" (11178 bytes)
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.
