signals are not IPC!

[Henry Spencer]

	...Personally I think that signals, along with file security
	are the two most mis-designed features of UNIX...

	...It seems that signals need to be treated even more like
	hardware interrupts.  One should be able to disable them and
	have signals sent during the disabled period saved for when
	they are enabled again...

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