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=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED 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 1A6C621351 for ; Sun, 19 Jan 2025 12:20:50 +0100 (CET) Received: (qmail 3249 invoked by uid 550); 19 Jan 2025 11:20:45 -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 x-ms-reactions: disallow Received: (qmail 3211 invoked from network); 19 Jan 2025 11:20:45 -0000 From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com References: <87ed10mojw.fsf@mid.deneb.enyo.de> <20250118113112.GN10433@brightrain.aerifal.cx> Date: Sun, 19 Jan 2025 12:20:34 +0100 In-Reply-To: <20250118113112.GN10433@brightrain.aerifal.cx> (Rich Felker's message of "Sat, 18 Jan 2025 06:31:12 -0500") Message-ID: <87bjw3kq2l.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [musl] Linked stream handling * Rich Felker: > On Sat, Jan 18, 2025 at 10:58:11AM +0100, Florian Weimer wrote: >> Some of us interpret POSIX that it requires or at least encourages a >> concept of linked streams: reading on from some streams may implicitly >> flush certain other streams. (The language in the standard around >> that is not particularly clear.) Linked streams may introduce >> deadlocks (particularly with explicit locking if flockfile), so POSIX >> suggests that implementations provide some form of deadlock detection, >> failing certain stream operations. >> >> Do I read the sources correctly, and musl does not implement any of >> this? > > musl very intentionally does not do any implicit flushing, because (1) > it necessarily incurs deadlocks, and (2) it's useless because portable > programs can't depend on it anyway but need to explicitly flush what > they want, and musl generally favors making programs do the portable > thing when there's no strong reason not to. > > I think the recommendation in POSIX to detect deadlocks is misguided > because any deadlock beyond some trivial same-thread stuff that's > unlikely to be the situation at hand is halting-equivalent to detect. > The POSIX recommendation should be to drop the whole misguided legacy > practice of auto-flushing that was invented in a single-threaded world > on C implementations that could only open a small single- or > double-digit number of FILEs at a time. Yes, it's surprising that this is still part of POSIX. Not implementing this things seems the right call. The the standard is not explicitly saying that such linked streams are required. The most direct hint is the suggestion to implement deadlock detection and fail flushing.