Date: Sun, 25 Oct 2020 20:50:29 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Status report and MT fork 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. 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.