Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!genrad!decvax!decwrl!pyramid!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: UNIX Facilities for Interpreters - (nf)
Message-ID: <21204@sun.uucp>
Date: Tue, 16-Jun-87 13:06:44 EDT
Article-I.D.: sun.21204
Posted: Tue Jun 16 13:06:44 1987
Date-Received: Thu, 18-Jun-87 02:27:18 EDT
References: <540@iscuva.UUCP> <8300006@iaoobelix.UUCP> <680@nu3b2.UUCP>
Sender: news@sun.uucp
Lines: 52

> WHAT is the benifit over an approprately set quantity of disk-block buffers?

1) You have a less kludgy interface (sorry, "vread"-type calls are
kludges).

2) You don't have to worry about the quantity of disk-block buffers;
if the file takes more blocks than are in your buffer cache, no
problem.

3) You don't tie up parts of your buffer cache for long periods of
time while the pages are in your address space after a "vread".

(Note also that there may be systems where there *is* no conventional
buffer cache *per se*; the system might just do something similar to
"mmap" inside the kernel to do "read"s and "write"s.  Don't make
assumptions about how your OS works!)

> As the call defines a local buffer as teh second parameter as opposed
> to "one being assigned by the system" [according to the man page]
> it would seem to my uneducated mind that the individual in question
> is overlooking the fact that the normal disk read takes place with two
> levels of buffering already:
> 
> 1) disk block buffering <as in the tunable parameter>
> and
> 2) local process buffering <as in stdio.h>
> 
> his two layer buffering scheme is already taking place on a system wide
> level.  His solution would simply add a third level of buffering in
> the middle.

Huh?  If you "mmap" a file, there's only one level of buffering;
systems generally do not do paging I/O through the buffer cache.
Using "mmap" *reduces* the number of buffering layers, since the
local process buffer *is* the disk buffer.

> His "interpreter" point does not seem to make sense either
> because most interpreters load a file in it's entirity and "psudo-complie"
> them to get critical information <line numbers in BASIC and such>

Huh?  What is "his 'interpreter' point"?  The only thing I can find
in any of the responses that fits this description is Juergen
Wagner's point that interpreters usually let you modify the program
being interpreted, and thus that you can't share all of it under all
circumstances.  This point still stands; with copy-on-write, you can
probably arrange to share most of the code, assuming that the size of
the program being interpreted, in its internal form (most
interpreters don't run directly off the source code), is large
relative to the page size (or some similar quantum) of the system.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com