Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.arch Subject: Re: Multics & Memory mapped files Message-ID: Date: 11 Feb 90 18:24:47 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: peter@ficc.uu.net (Peter da Silva) Organization: Xenix Support, FICC Lines: 23 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!!! Why? Nobody said you had to map the file in from the beginning. Even on a PDP-11, there's no problem with seeking to location 2^20 and starting the mapping from there (or using whatever mechanism you want). Nobody is denying that both techniques have advantages in certain domains: for example, it's hard to memory map a serial port. But this isn't one of them. > 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? They used multisegment files, which was probably a pain. > 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. As do stream files. -- _--_|\ Peter da Silva. +1 713 274 5180. . / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'