From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 73FEC2483A for ; Thu, 25 Jul 2024 02:19:33 +0200 (CEST) Received: (qmail 30533 invoked by uid 550); 25 Jul 2024 00:19:25 -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 30441 invoked from network); 25 Jul 2024 00:19:25 -0000 Date: Wed, 24 Jul 2024 20:19:18 -0400 From: Rich Felker To: libc-coord@lists.openwall.com Cc: musl@lists.openwall.com, libc-alpha@sourceware.org Message-ID: <20240725001917.GJ10433@brightrain.aerifal.cx> References: <20240724190948.GH10433@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [musl] Re: [libc-coord] Making exit actually thread-safe On Wed, Jul 24, 2024 at 05:21:00PM -0400, enh wrote: > you didn't want to go with the recursive mutex variant mentioned? i'm > convinced by this change for Android too, but was leaning towards the > recursive mutex myself... The change I'm advocating for first is a minimal one, just making calls from other threads well-defined by blocking until the process terminates. This is a trivial change that any implementation can adopt without breaking anything else, and doesn't have any potential far-reaching consequences. While some implementations may want to allow (or feel they already allow, often by accident) recursive calls to exit, imposing a requirement to do this without a deep dive into where that might lead seems like a bad idea to me. Even if it is desirable, it's something that could be considered separately without having the thread-safety issue blocked on it. By leaving the recursive case undefined as it was before, any implementations that want to do that or keep doing that are free to do so. Rich > On Wed, Jul 24, 2024 at 4:53 PM Konstantin Belousov wrote: > > > > On Wed, Jul 24, 2024 at 03:09:48PM -0400, Rich Felker wrote: > > > Inspired by Rust issue 126600, there seems to be renewed interest in > > > the (non-) thread-safety of exit, namely the C (and copied in POSIX > > > text) stipulation that calling exit "more than once" results in > > > undefined behavior. > > > > > > This language predates threads and thus was certainly written with > > > recursive calls (via atexit handlers) in mind as the way one might > > > come to call exit "more than once". > > > > > > My view is that making calls to exit from multiple threads (one or > > > more additional threads while the first caller is still acting on > > > exit) undefined is a mistake and is harmful. There is a clear unique > > > reasonable behavior for this situation: any remaining callers block > > > until the first call to exit has finished, at which point they no > > > longer exist. Leaving exit via longjmp, exceptions, etc. is undefined, > > > so there are no concerns about what happens in such a situation. The > > > additional calls to exit all behave as expected: the process > > > terminates. > > > > > > Currently there is a glibc tracker item, #31997, and an Austin Group > > > (POSIX) tracker item, #1845, open for this topic, as well as the > > > original Rust tracker thread. I have participated in all of these, and > > > would like to move this forward towards consensus on whether any new > > > thread-safety requirement should be adopted, and if so, what the > > > specific semantics should be. > > > > > > Links: > > > > > > https://github.com/rust-lang/rust/issues/126600 > > > https://sourceware.org/bugzilla/show_bug.cgi?id=31997 > > > https://austingroupbugs.net/view.php?id=1845 > > > > I do think that the wording in the austin group bug is reasonable, and > > intend to do that for FreeBSD, https://reviews.freebsd.org/D46108