Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 7/7/83; site rlgvax.UUCP Path: utzoo!linus!security!genrad!decvax!harpo!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: signals are not IPC! Message-ID: <831@rlgvax.UUCP> Date: Sun, 17-Jul-83 02:48:14 EDT Article-I.D.: rlgvax.831 Posted: Sun Jul 17 02:48:14 1983 Date-Received: Sun, 17-Jul-83 13:17:08 EDT References: <3087@utzoo.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 33 I agree; we have some code that use signals and pause() as a block/wakeup mechanism as part of a kludgy IPC mechanism using files as mailboxes. If we had ANY usable IPC at all, even the relatively primitive System III named pipes, we'd ditch the current crock in a minute (our problem is that we still support our software on VAXes running 4.1BSD, which don't have named pipes, and on our own machines for which the latest public release of UNIX doesn't have named pipes). However, you do need some way of forcibly getting the attention of another process for those truly asynchronous cases. In some of those cases you could poll an IPC channel, but in other cases that would be too inefficient and would require putting polling code in lots of places. With shared memory it might be possible to handle these cases by having a separate process service the interrupts (for example, Xerox's Pilot operating system does this for hardware interrupts, treating an interrupt as a process wakeup; on the other hand, the Xerox Mesa Processor has firmware support for process blocking/wakeup/ switching); I can't speak for whether this would be fast enough for all applications (people *do* use UNIX as a real-time operating system - note, operating system, not "executive"; there are applications that need real-time processing and the facilities of a general-purpose operating system, and frankly I'd like to see UNIX be able to do that better than VMS or RSX-11). You do need the ability to reset the signal action to something other than SIG_DFL when the signal is caught (if you're going to permit ANY action for a signal other than SIG_IGN or SIG_DFL, this is necessary to close the gap where two signals in a row blow the process away WITHOUT giving it a chance to clean up). Also note that the signal mechanism has been used for other purposes than killing processes for quite a while; "ed" catches SIGINT and aborts the current command, returning you to command level, and has done this since at lease V6 - many interpreters do the same. Guy Harris {seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy