🚀 go-pugleaf

Everybody seems to be missing the crucial fact about memory mapped files!

They ONLY work for cases where the file size is < virtual address space!!!

They are not a a generally useful solution which works over all possible
implementations.  UNIX file I/O does work over all situations!

In particular, the example of having to read sequentially through a file,
collecting info from each record in turn, works fine in UNIX on a PDP-11,
if implemented as fseek/fread/...
whereas if the memory mapped file paradigm was used, the largest file
you could handle would be, say 40k bytes(11/45, 11/70), clearly not an
interesting upper limit.

You can, under UNIX, do a stat(2) type call, get the file size, 
grow memory if necessary, and then read the whole dang file into memory.
If you're really going to look at every page of the file I'm not
convinced that this would be a major performance penalty versus
memory mapped I/O.

Now try to port that code to an 8088/80286/80386 running in 8086 mode.

With enough funny hardware and restrictions on saving pointers, I guess
you could trap increments of address registers when they crossed a
segment boundary.

If I recall properly, Multics hardware couldn't address more than 2^18
words(?) per segment.  While that was huge at the time, it isn't all
that interesting now as an upper limit.  What, if anything, did the
programmer do to handle files > 1 segment in length?

This is not to say that memory mapped files are a "BAD IDEA", just
that they have limits that must be considered by the programmer.

Rich Hammond