Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/26/83; site ihuxx.UUCP Path: utzoo!linus!decvax!microsoft!uw-beaver!cornell!vax135!ariel!houti!hogpc!houxm!ihnp4!ihuxx!ignatz From: ignatz@ihuxx.UUCP Newsgroups: net.unix-wizards Subject: Re: signals are not IPC! Message-ID: <482@ihuxx.UUCP> Date: Tue, 26-Jul-83 01:34:55 EDT Article-I.D.: ihuxx.482 Posted: Tue Jul 26 01:34:55 1983 Date-Received: Tue, 19-Jul-83 17:44:48 EDT References: <3087@utzoo.UUCP> Organization: BTL Naperville, Il. Lines: 48 One of my pet peeves is people who try to use a wrench as a hammer and then complain because it doesn't do a good job. Signals were never intended as a general interprocess-communication scheme, and anyone who tries to use them as such deserves what he/she gets! Signals are basically a way of killing a process, with some minor and less-successful arrangements grafted on to permit such a process to clean up first. Trying to patch them up into a general IPC scheme is foolish -- it would be much better to take the time and effort to figure out what is really wanted for the job, and then do it right as a completely separate facility. And the last thing we need at the software level is to re-create the full ugliness of hardware interrupts! This will merely force the application-level programmers to re-invent all the solutions to the problems interrupts cause. A far superior way to proceed would be to provide some relatively safe, relatively simple, relatively clean facility like message-passing. I agree that the lack of a general IPC mechanism is a major wart of Unix. And the signal mechanism could stand some improving to make it into a better and more foolproof way of terminating processes while allowing them to clean up. But trying to pervert the same mechanism to meet both needs is a dubious approach, and complaining because standard Unix signals don't do both jobs is just plain stupid. -- Henry Spencer U of Toronto {allegra,ihnp4,linus,decvax}!utzoo!henry Now, mind that it's rather late, and I may well miss some details; but I'll attempt to be reasonably complete in the following statements. Yes, you're quite right...signals were never meant to be a general-purpose IPC mechanism. However, they were meant to be more than just 'cleanup'. Look at 'The UNIX Time-Sharing System', The Bell System Technical Journal, July-August 1978 (commonly known as the 'UNIX BSTJ'); on page 1925, section VII (Traps), Ritchie and Thomson explicitly make the point that the signal mechanism is intended to allow the programmer to handle just the type of situations that are handled with TRAPS. Yes, Virginia, signals were intended to be trap-handler type mechanisms. It is quite true that signals should not have the horrendous windows that they do; and they are NOT IPC mechanisms. But they *are* intended to handle program exceptions. Ta, Dave Ihnat ihuxx!ignatz