Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP Path: utzoo!linus!decvax!genrad!grkermit!masscomp!clyde!ihnp4!fortune!rpw3 From: rpw3@fortune.UUCP Newsgroups: net.unix-wizards Subject: Re: Re: signal handling in 4.2: Is this - (nf) Message-ID: <2164@fortune.UUCP> Date: Tue, 3-Jan-84 19:11:25 EST Article-I.D.: fortune.2164 Posted: Tue Jan 3 19:11:25 1984 Date-Received: Thu, 5-Jan-84 01:11:20 EST Sender: notes@fortune.UUCP Organization: Fortune Systems, Redwood City, CA Lines: 85 #R:hou3c:-13500:fortune:11600038:000:4564 fortune!rpw3 Jan 3 12:15:00 1984 ***** fortune:net.unix-wizar / utzoo!henry / 4:20 pm Dec 20, 1983 While I fully agree with Rob Warnock that signals are not software interrupts, that they were never intended as such, and that anyone [1] -> who uses them as such is insane and deserves what he gets... May the gods preserve us from people who think real software interrupts are wonderful and desirable!!! Why do you think the first act of [2] -> practically every decent operating system in existence, when it gets an interrupt, is to turn it into something more civilized (e.g. a wakeup or a semaphore operation)? Interrupts are an ugly, low-level, terribly error-prone form of communication. I agree that Unix could use better interprocess communication (and that signals were never intended to be such), but real software interrupts are the *last* [3] -> thing we want! Higher-level primitives, **PLEASE**! -- Henry Spencer @ U of Toronto Zoology The Concurrent Euclid model is indeed one of my internal refence models when thinking about such things (c.f. Holt, R. C. "Concurrent Euclid, The UNIX System, and Tunis", Addison-Wesley 1983). As part of a performance analysis task, we implemented a Euclid-style "simulation kernel" which allows multiple "processes" in one UNIX-process (c.f. Bakul Shah's articles on "nargs()"). It works just fine doing Simula-like simulations, but when you start hooking it to the outside world what happens? You need REAL INTERRUPTS as the thinnest, bottom-most layer of the structure to drive your semaphores (actually, priority condition queues). Please understand the constraint of more-or-less "standard" UNIX. In terms of your note, I am TRYING to impose higher-level primitives [3], as as fast as I can [2], and may well be insane [1] to expect to be able to do it easily under UNIX. Unfortunately, standard UNIXes do not allow multiple processes to share easily and completely the same address space, as is needed for efficiently implementing semaphore-based multiprogramming (not even System-V, really). Clean software interrupts ARE a useful basis for higher-level primitives; other operating systems have provided them to users. When complete soft-int's are provided, the code gets CLEANER, since you can handle each interrupt as a "message" from the operating system that the world is changed in some interesting (to you) way. (In fact, on some systems, soft-ints are solely used to handle messages.) However, no commercial UNIX I know of treats kernel events as messages to the user process. (I believe there was some CMU experimental work that treated ALL system calls and returns as messages, which would be completely equivalent to the software interrupts I suggested.) It has even been noted that the two most common styles of operating systems, the procedure-call/monitor model and the message-passing model, are in fact completely equivalent. [Lauer & Needham, "On the Duality of Operating System Structures", Operating System Review v13 #2 (Apr'79) pp3-19]. It was noted that attempts to do both generally were quite messy. UNIX and Euclid both fall in the prodecure-call/monitor camp, and I suspect efforts to graft messages on without clean interrupts will result in further hackery. The 4.2BSD "select" is insufficient, NOT because of the basic style of the mechanism, but because it does not go far enough. I would be almost satisfied with a "select" instead of "software interrupts" if the "select" could return a "completion code" for ALL of the events the program needs to know about: child died, hit, timeout expired, read complete, write complete, packet sent, IPC received, etc. ("Select" still doesn't allow the process to run CPU-bound while handling I/O in the "foeground", though. I believe that the user process should also have some say in how its background scheduling is handled.) In summary, the definition of "civilized" [2] depends on where you stand. Current UNIXes do not allow you do do a wait-for-any-interesting- condition. It is not clear to me that the pure semaphore model (one of several reputable models) fits well into UNIX. A clean software interrupt system or a complete message system might be better. My vote (currently), based on the amount of work and on upward/downward compatibility issues, is for clean interrupts. Given that, the other mechanisms can be built as wanted/needed. Rob Warnock UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3 DDD: (415)595-8444 USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065