Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: johnl@ima.ISC.COM (John R. Levine)
Newsgroups: comp.std.unix
Subject: Re: UNIX Facilities for Interpreters
Message-ID: <8281@ut-sally.UUCP>
Date: Tue, 16-Jun-87 15:53:13 EDT
Article-I.D.: ut-sally.8281
Posted: Tue Jun 16 15:53:13 1987
Date-Received: Sun, 21-Jun-87 09:30:55 EDT
References: <8250@ut-sally.UUCP>
Sender: std-unix@ut-sally.UUCP
Reply-To: ima!johnl@harvard.harvard.edu (John R. Levine)
Organization: Javelin Software Corporation
Lines: 35
Approved: jsq@sally.utexas.edu (Moderator, John Quarterman)
Summary: file mapping is a reasonable idea, do it right.

From: johnl@ima.ISC.COM (John R. Levine)

In article <8250@ut-sally.UUCP> boba@iscuva.ISCS.COM (Bob Alexander) writes:
>[interpretive languages would work better if they could page their data
>memory like compiled languages do, so how about a vread() call that maps
>instead of reading?]

When we were designing AIX, the Sys V port for the RT PC, the same question
of file mapping came up, this time in the context of doing data base work.
The original proposal was for something like the vread() call, but we
eventually decided on, essentially:

	pointer = filemap(fd);

where fd is an open file descriptor.  It maps the entire file into the
address space, somewhere, and gives you a pointer to it.  It fails if there
isn't enough address space.  This had the advantage over the vread() approach
that it generalizes better for file writing -- if the file is mapped
read/write, anything you write to the segment goes into the file, adding
new blocks into the file if need be.  If you don't want the file's size to be a
multiple of a page, use ftruncate() to set its length.

Notice that vread() can easily be simulated by this scheme, but not vice
versa.  I agree that this scheme fails dismally if you don't actually have
paged memory, but I'd rather have this as the underlying call and vread() as
a library routine that maps on systems where it can and reads on systems
where it can't.

John Levine, ima!johnl or Levine@YALE.somethingorother
---
John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400
{ ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something
U.S. out of New Mexico!

Volume-Number: Volume 11, Number 68