Article View: comp.arch
Article #22429Re: the Multics from the black lagoon :-)
From: David Collier-Brown
Date: Tue, 13 Feb 1990 13:22
Date: Tue, 13 Feb 1990 13:22
48 lines
2954 bytes
2954 bytes
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.
Technical Details
Message-ID:
<7530@yunexus.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!jarvis.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!davecbReferences:
<10468@alice.UUCP>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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