Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!bloom-beacon!wesommer
From: wesommer@athena.mit.edu (William Sommerfeld)
Newsgroups: news.config
Subject: Re: (*Hiccup*) pyramid overflows /usr/spool
Message-ID: <1210@bloom-beacon.MIT.EDU>
Date: Tue, 28-Jul-87 03:51:03 EDT
Article-I.D.: bloom-be.1210
Posted: Tue Jul 28 03:51:03 1987
Date-Received: Wed, 29-Jul-87 04:30:44 EDT
References: <3834@pyramid.pyramid.com> <2523@hoptoad.uucp> <1650@sigi.Colorado.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: wesommer@athena.mit.edu (William Sommerfeld)
Followup-To: comp.os.misc
Distribution: world
Organization: Massachusetts Institute of Technology
Lines: 63
Keywords: MACH UNIX BSD Multics
Summary: CMU didn't do it first.  Try Multics instead..

A friend of mine who is an avid Multician says that all operating
systems seem to be approaching Multics...   This is a little off the
subject, but...

>We were testing MACH 1.0 on Boulder for about a week.  Now, while MACH 
>still needs work (scheduler doesnt quite handle niced proc's properly), 
>one item it features is resource pausing.  In effect, when a disk reaches 
>it's capacity, any system call that terminated due to lack of space or 
>inodes causes the process (thread?) to "pause".

Multics does something like this.  Since the shell and the commands it
executes run in the same process, rather than suspending the process,
it pushes a new shell after printing an error message.  If the shell
returns, the process continues running right from where it left off.
You can clean up and restart, abort the command, or go into the
debugger and poke around (you don't have to realize that you need the
debugger in advance of running the program, which is a major win). 

Exercise for the reader: Figure out what happens when there's a bug
(of a kind which would normally result in a shell being pushed) in the
routine which prints the prompt for the shell.  Hint: the user's stack
is limited in size. 

>It also sends a message 
>to the controling terminal (somewhat useless when most daemons run without
>one).  

Ramble 1: Multics deals with this by having every daemon run attached
to a "channel" (sort of like a pseudo-terminal); output goes into a
log file, and input comes from a mailbox.. if you send a message to
the mailbox, the daemon eventually wakes up, reads the message, and
stuffs it into its input stream.  (Needless to say, control mailboxes
are protected so that only the appropriate users can write to them).
It's useful for debugging daemons -- if something dies, a message
explaining why (usually) shows up in the logs, and if it gets noticed,
it can be debugged or repaired under "remote control", by sending a
line at a time of input to the subprocess.  Much better than the
typical "Hey!  what happened to the mailer?" "I don't know.. it was
running a minute ago." (Wait 1 minute) "Looks like the nameserver's
dead.. where'd it go?" (Wait 1 minute) "Hmmm...  /core looks like it
came from named" "Where'd my unstripped version of named go??" that
goes on when a network daemon drops dead under strange circumstances. 

Ramble 2: I generally find the idea of having the kernel write to the
user's controlling terminal to be a pretty disgusting modularity
violation.  What if the process is running under a window system, and
doesn't have a controlling terminal, or the "controlling terminal" is
a terminal emulator which is iconified?  I _hope_ that there's some
way to catch the signal/error involved, invoke my handler, and pick up
right where you left off.  I'd rather have the shell set up a handler
& print the appropriate message.  Worst offender in this category:
Ultrix 2.0, which blats out a "file system dirty - run fsck" message
to the users' terminal before returning "mount device busy" if you try
and mount a filesystem which wasn't unmounted cleanly.  How is the
kernel supposed to know that I didn't rename "fsck" to "chkdsk" for
MS-DOS compatibility. ;-)

>--- 
>Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-4991) 
>forys@boulder.Colorado.EDU -or- ..!{hao|nbires}!boulder!forys

					Bill Sommerfeld
					wesommer@athena.mit.edu