Path: utzoo!attcan!uunet!cs.utexas.edu!jarvis.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!davecb
From: davecb@yunexus.UUCP (David Collier-Brown)
Newsgroups: comp.arch
Subject: Re: the Multics from the black lagoon :-)
Message-ID: <7530@yunexus.UUCP>
Date: 13 Feb 90 13:22:30 GMT
References: <10468@alice.UUCP>
Organization: York U. Computing Services
Lines: 48

dmr@alice.UUCP writes:
| What actually happened was that, for the most part, people
| avoided the "single-level store" for data and used sequential
| IO via read and write calls.  The Multics IO system was quite
| snazzy, and one of the first things we did with it was to write
| the "fsim"-- the file system interface module, that initiated your
| segment and put/got bytes in it, and did all the
| grotty but necessary things like set_bit_count.  In other words,
| as a "feature," occasional use of data file mapping was convenient,
| but as an organizing principle, as a way of life, it was a bust;
| it was something that had to be programmed around.

  I got caught on this one too: it was a serious pain to simulate a stream of
characters with an array.  The two are different **in nature**, and the
result is repeated brain-faults by programmers (:-)).

  I claim the unification of the file/segment namespace was a good idea, but
the unification of the "access methods" was ill-advised.  
  To be specific:  I once wrote a program that did random i/o.  Its Multics
variant started out using the simulation of "file" behavior of fsim (ioa_,
methinks, in the version I used).  At some point, I discovered the
underpinnings of the module was a memory mapping, something I had no
experience with nor intuitive understanding of.  
	Surprise! 
	This low-level construct was exactly what I didn't need: it added
complexity, it had to be programmed around, it wasn't easy to understand.
Not having seen Unix at the time, I didn't think of the elegant "seek", I
instead thought of arrays  and "record[126,5]".  Bleaaaaaaa.

	I'll claim that one can usefully build several complete,
self-consistent views of a memory-mapped file, at least one based on streams
(sequences) of data, another on lines/records/structures of data, another
on monotonically increasing bifurcated but synchronized streams of data
(keyboard i/o) and so forth, about which an applications programmer can
reason and even intuit.  What I won't claim is that a "memory array of
file-contents" is the kind of view I'd use in an application.  

	Its a primitive.  Its even a "good" primitive, in that one can use
it to build lots of other, usefull things.  But anybody who uses primitives
to do substantial work **is** a primitive.(:-)).

--dave
	
-- 
David Collier-Brown,  | davecb@yunexus, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | Joyce C-B:
CANADA. 416-223-8968  |    He's so smart he's dumb.