Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utcsrgv.UUCP Path: utzoo!utcsrgv!mason From: mason@utcsrgv.UUCP (Dave Mason) Newsgroups: net.unix-wizards Subject: Re: Re: signal handling in 4.2: Is this - (nf) Message-ID: <3041@utcsrgv.UUCP> Date: Thu, 5-Jan-84 15:48:23 EST Article-I.D.: utcsrgv.3041 Posted: Thu Jan 5 15:48:23 1984 Date-Received: Thu, 5-Jan-84 16:35:36 EST References: <2164@fortune.UUCP> Organization: University of Toronto/Ryerson Polytechnic Institute Lines: 79 ***** 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 Rob Warnock replies: 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 .... 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 .... 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. .... Rob Warnock ...!fortune!rpw3 I agree with Rob, real software interrupts are usable to build higher level primitives (after all real hardware interrupts ARE used to build higher level primitives), but that doesn't mean that they are the right approach. In particular the question that it doesn't address is providing information about co-operating tasks to the operating system so that it may be able to improve the scheduling. It also means a fair amount of hacking to build the higher level primitives. And it doesn't address civilized I/O by the co-op tasks. The right solution requires looking at how the O/S is implemented..shareable address space & synchronization primitives & private I/O. Those are the facilities that the O/S should be providing to the user tasks. The problems are in how to combine this with security for the user tasks & the O/S itself. My approach is to make address space & process-hood independent, and to make address spaces tree structured. Processes being independent of the address space means that you can use things like Concurrent Euclid to solve real problems requiring concurrency within the confines of an O/S. Each process can execute independently (using multiple processors if available) doing I/O etc. and synchronization is handled by the O/S knowing about monitors & conditions. The tree structured address space is used to facilitate interactions between unrelated processes (a little detailed for this note). I won't argue semaphores/monitors or monitors/messages, but I personally feel monitors are the right way to go. Hopefully others will implement these kinds of facilities for user tasks using these alternate approaches. -- Dave Mason, U. Toronto CSRG, {utzoo,linus,cornell,watmath,ihnp4,allegra,floyd,decwrl, decvax,uw-beaver,ubc-vision}!utcsrgv!mason