Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!ucsdhub!jack!man!nu3b2!rwhite From: rwhite@nu3b2.UUCP (Robert C. White Jr.) Newsgroups: comp.unix.wizards Subject: Re: UNIX Facilities for Interpreters - (nf) Message-ID: <680@nu3b2.UUCP> Date: Tue, 16-Jun-87 03:14:20 EDT Article-I.D.: nu3b2.680 Posted: Tue Jun 16 03:14:20 1987 Date-Received: Sun, 21-Jun-87 06:34:40 EDT References: <540@iscuva.UUCP> <8300006@iaoobelix.UUCP> Organization: National University, San Diego Lines: 57 Summary: Disk BUFFER vs. Memory MAPPED files? In article <8300006@iaoobelix.UUCP>, wagner@iaoobelix.UUCP writes: > I endorse Guy Harris' posting. In addition to his remarks, note the following: > > with UNIX' shared images: only the text portions are shared among processes, > data areas reside in a process-private space. I think, however memory mapping > of files is a good idea, anyway, if used with large (read-only) data files > accessed by several users (e.g. font descriptor files). My questin stil stands... if the following are intended to be true: 1) Files will be read into system-wide shared memory space. 2) previously unused files and/or file segments will be read into virtual memory as such parts are requested. 3) as long as some "open"s are valid all attempts possible are made to keep said files in memory. 4) request/space conflicts will be handeled in an intellegent manner WHAT is the benifit over an approprately set quantity of disk-block buffers? if 2 is fales either the choice of files will be limited or the entire file will be read into memory even if only part is needed. If 3 is false the system will devour it's resources. If 1 is false then their is no point to any of it because the dataspace would be private. If 4 is false the system would halt at the instant the shared space ws full. 1 - 4 are the disk block buffering rules [as near as I learned them] 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 and 2) local process buffering 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. 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 This extra layer of buffering would seem an unnecessary drain on services to me. NOTE: It is possible that I have COMPLEETLY mis-understood his intent, but after three or four readings of the preposed command/function description someone is going to laborusly explain, point by point, the difference between what I have expressed and what he intended if I have infact got it wrong. Robert.