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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 BDB7122DC8 for ; Thu, 25 Jul 2024 14:49:04 +0200 (CEST) Received: (qmail 1658 invoked by uid 550); 25 Jul 2024 12:49:00 -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 1611 invoked from network); 25 Jul 2024 12:48:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1721911730; x=1722516530; darn=lists.openwall.com; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=wnEHJX4RxzQUr+UtSAluykyYw0gB2RHrTP2cttB/v0s=; b=sVwhn2WadLaOTmJsJyra2zbYvbQxRXs0knqQbiCbvSilLwEQQY4ZNRozZ7sjF98G7s be4NZEcw66c/Ap2vpbBC5dGZb/GKwwUz5Fkmh5mJEI6DxAqX/fFWMCvYdAwizkenfyWv Rieuql4znQpYOj/A1J45L2ErSfEiX8j57EGnoR85mdOitpde7+6wH04gy62l0+7py3oJ XL3vWfxWWMUD6VQjIbEdT/yyrZrB8atGRFFCUgEaVLmt6vN2jzdYNx+ptC1oVHgWYPFj 1pRfSt0iyO69vkpKIFxUjSZk5kmQaGw8mX7VsPoVbyeGMzCElMv5hiQ+0iKzIyvS/V7C BBtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721911730; x=1722516530; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wnEHJX4RxzQUr+UtSAluykyYw0gB2RHrTP2cttB/v0s=; b=LdI1HXxYCvQpftkG+aaEUjFF1MJgfSMpo7VNr5dOtc28zmsU0gDkKWz8+SLPh93sC9 rku3A4f2HCv/eoNMBoClwZS5A/P7boQRi1vdoYXqdGCwk3pYwuBzWmfQ0A/6ZX+NIKet A0TXCG0Kroxwti+fBpCECwCbGAvaqHbKzhSljGj2BOozm4kLTWS2+OfTSEqj9imnk8Cn hFeALgpHcPtpw/w2snZ5kWvKug70Yaj86eUO18L7m2cU5HZLCpVTH1BkfpE4R83OXpbD PWNQiW2Q4IvasGeTK8yQOLrvphq0CeLe4tCb+ElCcRycuBFhv+CiTMJcUKhUGnnNbLgK bvHA== X-Gm-Message-State: AOJu0YziawFduLNWIPhy1qckqO4jZVwpULF8Sp+P2f5riiLDJR3qCxmC 464hb0/JE3GrGehuqKvEQrraBHcLaIPckt7Ce9qEFPVfIzkfoQpE4NprFnVMZaw= X-Google-Smtp-Source: AGHT+IH7dbHURun3rqHaV/I2wKefzyGddJ3Iy/dOnQ0hKEnaMVLazz4xGT6sVtytDiEQcWHuPn1Rsw== X-Received: by 2002:a05:6870:9111:b0:25e:14f0:62b1 with SMTP id 586e51a60fabf-264a0d6ce30mr3115633fac.13.1721911730233; Thu, 25 Jul 2024 05:48:50 -0700 (PDT) Message-ID: Date: Thu, 25 Jul 2024 09:48:46 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: libc-coord@lists.openwall.com, enh Cc: musl@lists.openwall.com, libc-alpha@sourceware.org References: <20240724190948.GH10433@brightrain.aerifal.cx> <20240725001917.GJ10433@brightrain.aerifal.cx> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [musl] Re: [libc-coord] Making exit actually thread-safe On 25/07/24 09:39, enh wrote: > On Wed, Jul 24, 2024 at 8:19 PM Rich Felker wrote: >> >> 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) > > yeah, i think that was what made me lean toward the recursive mutex > --- the assumption that _that's_ the option least likely to break > anyone. (i actually thought that was the point of even mentioning it > in the proposal --- the assumption that someone somewhere has an > atexit() handler that calls exit(). normally at this point i'd say "if > i've learned one thing in a decade+ of dealing with Android's libc and > the third-party binary app ecosystem, it's that no matter how crazy a > thing, if you can imagine it, someone's relying on it already", but > since "exiting" isn't really a thing on Android -- you're either > backgrounded or kill -9'ed, and don't typically have any kind of > "quit" functionality yourself -- this is one place where it seems > relatively unlikely.) > >> 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. > > aye, but a program that calls exit() from an atexit() handler is > working for me right now on Android, glibc, and macOS. so there's a > user-visible behavior change here for any of those libcs that goes > with a non-recursive mutex. (i think the same is true for musl too, > but don't have a musl-based system to test on.) I think it is reasonable to not add the constraint to allow recursive exit, although making this implementation defined will most likely pressure to eventually have the resolution on the most used behavior (unless it is broken by design). At least for glibc, my plan is to keep current support of allowing it so mostly likely we will use a recursive mutex.