Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!crdgw1!sunroof!hammondr From: hammondr@sunroof.crd.ge.com (Richard A Hammond) Newsgroups: comp.arch Subject: Re: Multics & Memory mapped files Message-ID: <5180@crdgw1.crd.ge.com> Date: 9 Feb 90 14:19:19 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> Sender: news@crdgw1.crd.ge.com Organization: General Electric Corporate R&D Center Lines: 35 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