🚀 go-pugleaf

In article <131682@sun.Eng.Sun.COM> gingell@sun.UUCP (Rob Gingell) writes:
>... At the very least, the read() version will be slower
>than the mmap() version by the amount of time required to effect the
>copies from kernel to program buffers...

Assuming your MMU can do copy-on-write, why copy?

>... read() gives you a copy of the file data
>at the time that the call is executed.  That copy is immutable save any
>action performed by your program.  If read() were implemented *as* mmap(),
>then while it is possible to deal with side effects introduced in *your*
>machine, it is not, in general, possible to deal with side effects introduced
>in other machines...

Why are other machines relevant?  Can they reach into your machine and
mess with memory?  Or are you assuming an implementation where other
machines are not told "I'm using this data, and want to be told before
anyone else starts to change it"?

Clearly, implementing read with copy-on-write mapping requires a proper
implementation of copy-on-write, in which *any* attempt to mess with the
data triggers a copy operation.  If some defective file system, call it
NFS (name picked purely at random :-)), is not capable of supporting
copy-on-write, then you can't do this optimization when the file is on
the other end of NFS.  If, on the other hand, you have a real file system,
it's not a problem.  Concurrent access to files is actually quite rare
except for directories and certain system files; a copy-on-write read
would almost never need to copy.
-- 
"The N in NFS stands for Not, |     Henry Spencer at U of Toronto Zoology
or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu