From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1030 invoked from network); 26 Oct 2020 00:50:46 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 26 Oct 2020 00:50:46 -0000 Received: (qmail 21950 invoked by uid 550); 26 Oct 2020 00:50:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 21913 invoked from network); 26 Oct 2020 00:50:41 -0000 Date: Sun, 25 Oct 2020 20:50:29 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20201026005028.GI534@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [musl] 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