🚀 go-pugleaf

In article <10468@alice.UUCP> dmr@alice.UUCP writes:

| 2) In the state of technology, even plain files cannot be mapped
|    properly, because they are too big
| (I might need some correction on the second point, but I don't
| see how the Multics machine could deal transparently with
| segments larger than 256KW.)

  Sure. I could quibble about the size, obviously 1MB is too small, but
there will always be a need for a file larger than the address space.
You get some real problems seeking into a file which is larger than you
integer size, too, whether you use the value as a subscript or offset.
You obviously need a data type which can hold the largest filesize and
do arithmetic with it if you want it to be convenient. Anyone who has
used really large files on typical UNIX knows the problems.

| What actually happened was that, for the most part, people
| avoided the "single-level store" for data and used sequential
| IO via read and write calls.  

  I suspect that this was due to the limitations of the implementation
to a large extent. If the mapping had been smooth and seamless it might
well have been more used.

|                                                  In other words,
| as a "feature," occasional use of data file mapping was convenient,
| but as an organizing principle, as a way of life, it was a bust;
| it was something that had to be programmed around.

  I think that follows. You hit the limits all the time, therefore you
did it another way.

  I haven't had access to Multics on a regular basis for about 15 years.
If anyone cares to run a file access test of i/o vs mapped methods, such
as another poster did for BSD, it might be interesting. Someone might
state the current filesize limit for mapping, too.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
            "Stupidity, like virtue, is its own reward" -me