Re: OT: Windows (Was: Re: Open Source does not mean easily

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.