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