henry@utzoo.UUCP (Henry Spencer) (07/13/83)
...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!henrynather@utastro.UUCP (07/15/83)
Inter-process communication:
If somebody *does* decide to modify Un*x to permit such communication,
please consider the possibility that multiple cpu's may be running
different processes that must communicate. Example: assuming only
one cpu, a LIFO stack works fine. With 2 cpu's, both with access
to the stack pointer, disaster results. A FIFO (mailbox) scheme is
ok so long as each cpu has its own pointer.
Ed Nather
...ihnp4!kpno!utastro!natherguy@rlgvax.UUCP (Guy Harris) (07/17/83)
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!guyignatz@ihuxx.UUCP (07/26/83)
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