* [musl] Linked stream handling
@ 2025-01-18 9:58 Florian Weimer
2025-01-18 11:31 ` Rich Felker
0 siblings, 1 reply; 3+ messages in thread
From: Florian Weimer @ 2025-01-18 9:58 UTC (permalink / raw)
To: musl
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?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [musl] Linked stream handling
2025-01-18 9:58 [musl] Linked stream handling Florian Weimer
@ 2025-01-18 11:31 ` Rich Felker
2025-01-19 11:20 ` Florian Weimer
0 siblings, 1 reply; 3+ messages in thread
From: Rich Felker @ 2025-01-18 11:31 UTC (permalink / raw)
To: Florian Weimer; +Cc: musl
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.
Rich
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [musl] Linked stream handling
2025-01-18 11:31 ` Rich Felker
@ 2025-01-19 11:20 ` Florian Weimer
0 siblings, 0 replies; 3+ messages in thread
From: Florian Weimer @ 2025-01-19 11:20 UTC (permalink / raw)
To: Rich Felker; +Cc: musl
* 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-01-19 11:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-01-18 9:58 [musl] Linked stream handling Florian Weimer
2025-01-18 11:31 ` Rich Felker
2025-01-19 11:20 ` Florian Weimer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).