Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.programmer
Subject: Re: OT: Windows (Was: Re: Open Source does not mean easily
Date: Tue, 7 Jan 2025 17:31:37 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vljodp$o9b$3@reader2.panix.com>
References: <uu54la$3su5b$6@dont-email.me> <vlioum$24bqm$1@dont-email.me> <vljcq9$sis$1@reader2.panix.com> <vGbfP.54357$XfF8.7280@fx04.iad>
Injection-Date: Tue, 7 Jan 2025 17:31:37 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="24875"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)

In article <vGbfP.54357$XfF8.7280@fx04.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <vlioum$24bqm$1@dont-email.me>,  <Muttley@DastardlyHQ.org> wrote:
>
>>>Thats not proper asych, its still sequential. Proper asynch is when the
>>>program execution path is directly modified by external events. Otherwise
>>>you could claim simply using the standard file I/O system is asynchronous
>>>programming as there's no guarantee that any data has been written to the disk 
>>>before write(), fprintf() etc return.
>>
>>This is conflating multiple things.  Most IO operations dealing
>>with the actual hardware _are_ asynchronous (this is what
>>McIlroy meant in the quote I posted earlier).  The system call
>>interface gives the program the illusion of those happening
>>sequentially, but that's not how the devices really work.
>
>Indeed, and it was subsequently recognized that more than
>the 'sync'[*] system call was required for applications to
>ensure data was successfully written to the underlying
>device.

Yup.

>Applications in those days (e.g. fsck) would access the
>raw character device using the unbuffered read() and
>write() system calls rather than using stdio.  A key
>characteristic of raw devices were that the hardware DMA would
>use the application buffer directly rather than copying
>the data to the kernel buffer pool first.

They still do!

>[*] I recall using 'sync;sync;sync' from the Sixth Edition
>command line more than once, before rebooting.


I've always felt the triple-sync thing was kind of superstition.

But this makes some sense when one considers that a sync would
trigger additional IO requests that would be scheduled, but
not necessarily completed.

Still, once disk drivers started optimizing write order and
thus divorcing ordering of requests to the device from the
chronological order the requests arrived in, all bets were out
the window.

>Subsequently APIs like fdatasync(2) and open flags
>such as O_DIRECT and O_DSYNC were added.
>
>>It turns out the simple model of early research Unix was
>>insufficient for handling all sorts of important use cases,
>>hence why interfaces like `select` and `poll` were added.
>
>Although to be fair, select(2) originated with BSD and is
>a bit less flexible than poll(2).

This is fair.

	- Dan C.