On Sat, Jan 15, 2005 at 07:56:03PM +0100, Marcin 'Qrczak' Kowalczyk wrote:
Pete Chown <1@234.cx> writes:
of course, [mmap] can only be done on a limited type of file on some architectures, so it should be an optimization under the hood rather than an exposed interface.
In particular, you have to be careful not to run out of address space on 32-bit architectures. If you try to do file access by mapping the whole file into virtual memory, you won't be able to handle files larger than 2G or so. You also have to be careful not to map a number of file chunks, which in total exceed the address space available.
Which means that it *should* be explicit, rather than done under the hood. It's a tradeoff, the programmer should be aware when to apply it, the runtime should not impose a policy which would be hard to reverse.
I was thinking of it as a better implementation of a stream interface (when available). a user-visible mmap facility would also be good but unrelated. In any case it is purely an implementation issue and not very relevant to the discussion (as long as we don't mandate anything that would rule out alternate implementations, which would be tough to do since we have to marshall between haskell and something else anyway). some papers on the subject for those that are interested are: Exploiting the advantages of mapped files for stream I/O http://www.cs.toronto.edu/pub/reports/csrg/267/267.ps IO-Lite: A Unified I/O Buffering and Caching System http://www.cs.rice.edu/CS/Systems/ScalaServer/io-lite-tocs.pdf (this one talks about an alternate OS interface to files which we might want to take advantage of if available) John -- John Meacham - ⑆repetae.net⑆john⑈