Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.arch,net.micro.16k,net.micro.68k
Subject: Re: Re: 24 bit vs. 32 bit address space
Message-ID: <5603@utzoo.UUCP>
Date: Fri, 17-May-85 12:28:35 EDT
Article-I.D.: utzoo.5603
Posted: Fri May 17 12:28:35 1985
Date-Received: Fri, 17-May-85 12:28:35 EDT
References: <983@watdcsu.UUCP> <2385@nsc.UUCP> <730@amdcad.UUCP> <5543@utzoo.UUCP>, <396@oliveb.UUCP>
Organization: U of Toronto Zoology
Lines: 40

> Suspending a process on an address fault is the esence of demand paging.
> Whether the suspension is for a disk read or a memory write by another
> process doesn't change things.  Assuming the hardware allows the
> segment to grow, the process can be suspended waiting for a write on the
> segment.

Of course.  But this *still* makes pipes different from ordinary files,
because a read off the end of an ordinary mapped-in file is probably an
error rather than a request to wait until the file grows.  Admittedly,
this is the sort of difference that a reasonably careful operating system
could handle invisibly.  That hadn't occurred to me before.

Note also that demand paging is not enough, unless you're willing to say
that pipes and files are always an exact number of pages long; you really
need segmentation hardware that works to the byte.

> Sorry, a pipe does NOT look like a normal file.  Try doing a seek on a
> pipe! ...

"Beauty is in the eye of the beholder."  The number of programs that do
seeks on inputs is miniscule compared to the number that don't.  (Even on
Multics, virtual-memory measurements show that most files are read in a
strictly sequential manner.)  For the vast majority of programs, which do
not try to seek on their inputs, pipes look exactly like files.

> Perhaps the problem with mapping a tty line into memory is that we are
> looking at the wrong level.  Lots of systems have memory mapped
> terminals.  A specific character in memory maps to a specific row and
> column on the screen.  Software to trap writes to "screen memory" and
> provide an optimized screen update (ala curses) would allow driving
> remote terminals.

This solves CRT terminals, although with some reservations about the
efficiency of the solution (you'll have to try to delay until you've got
a substantial number of updates for the screen, since one-char-at-a-time
is often fairly expensive in characters transmitted).  It does nothing
for most other devices, alas.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry