Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!sdcsvax!ucsdhub!jack!man!nu3b2!rwhite
From: rwhite@nu3b2.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: UNIX Facilities for Interpreters - (nf)
Message-ID: <684@nu3b2.UUCP>
Date: Thu, 18-Jun-87 02:49:21 EDT
Article-I.D.: nu3b2.684
Posted: Thu Jun 18 02:49:21 1987
Date-Received: Sat, 20-Jun-87 01:02:33 EDT
References: <540@iscuva.UUCP> <8300006@iaoobelix.UUCP> <680@nu3b2.UUCP> <544@iscuva.ISCS.COM>
Organization: National University, San Diego
Lines: 65
Summary: OK, then... ?

In article <544@iscuva.ISCS.COM>, boba@iscuva.ISCS.COM (Bob Alexander) writes:
> Robert, I think your reading a lot more complexity into this file
> mapping business than there needs to be.  The key points are:
> 
> Although the call looks something like a read, no data is actually
> transferred.  This file data is just mapped in to the caller's address
> space.

OK, so whare does the file come from??  Is it in a special disk
partition, and loaded at system boot time?

If no data is transferd, why does the call require an established
buffer pointer to an established buffer?

> The mechanism is completely independent from the file system buffer
> cache.

As I gathered, but for an open file the above questions aplied imply
that the system buffer catche & read could, and does, preform all the functions
of vread.

> The file's data is accessed just like a memory access.

Once again, what's the buffer for?  If it moves the pointer, what about
the allocate memory pointed to by the buffer pointer.  [required for
compatabality]

> Decisions about what parts of the file are read into real memory when
> are made by exactly the same mechanisms as regular virtual memory.
> Parts (i.e. pages) of the file are simply paged in as needed.  No
> special tuning is required.

Can the file still be used normally?  how does the system know to page it?
does this pass through the system cache buffers?  If it does, isin't
this an extra buffering level?  Lastly, what if someone modifies the file
in a normal manner while it is in the page buffer?

> No consideration need be given to whether
> the file is open or not (in fact, the mapped file can be accessed
> after it is closed -- just like a "read" buffer can be accessed after
> the file is closed).  If a part of the file is frequently accessed, it
> will likely stay in real memory; if not it becomes a candidate to be
> swapped out.

This sounds like the purpose of the system buffers and read to me?

> The nice thing about mapped files is that, for the most part, they are
> just a repackaging of existing facilities.

As I said... What's the point?


Well, I feel that I have pounded that into the ground.  I sort of get the
picture, but it seems like one more thing to needlessly go wrong.  With
the 600 block buffer cache on my 4mb 3B2 The likely-hood of my second
read of the same material will be in cache is high enough, weather my last
opperation was a read or wtrite.

For the applications mentioned it dosn't sound like much of an asset because
it is an unstable addition to a stable functionality.

Thankyou for the comments.
Robert.

(-: Feeling dense or smug, but not shure which, in S.D. :-)