Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: Multics & Memory mapped files
Message-ID: <2115@crdos1.crd.ge.COM>
Date: 9 Feb 90 18:33:18 GMT
References: <8859@portia.Stanford.EDU> <20571@watdragon.waterloo.edu> <49956@sgi.sgi.com> <4791@helios.ee.lbl.gov> <2093@crdos1.crd.ge.COM> <1990Feb7.221800.804@utzoo.uucp> <2106@crdos1.crd.ge.COM> <5180@crdgw1.crd.ge.com>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 18

In article <5180@crdgw1.crd.ge.com> hammondr@sunroof.crd.ge.com (Richard A Hammond) writes:
| 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!

  You're right, but in general it doesn't matter. I looked over files on
about 200 Suns for large files, and the largest single file was under
100MB. Therefore for most applications there isn't a problem.

  I'm not disagreeing that a problem is not impossible, but it's really
uncommon. You have to support really large text and database files, but
the average application never get a large file by 32 bit standards.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
            "Stupidity, like virtue, is its own reward" -me