fostel@ncsu.UUCP (09/19/83)
This may seem an un-wizardly question, but why is the signal / kill
mechanism not suitable for a low bandwidth, simplememinded IPC system?
Yes, I know that certain "features" allow windows of vulnerablity; I'm
assuming I would close such windows by making the state after reception
of a signal be to ignore signals rather than die. Thus I might lose
a subsequent signal, but it would not damage me (or my process). With
any sort of reasonable handshake, such a lost signal would be quite a
tolerable thing. SO, in this context why are signals unsuitable? I can
imagine a multi-headed/tailed pipe shared among many children with reader
and writer notified of their duty via a signal. Again, you must presume
a nice set of procs to do the dirty work so it would not seem so kludgy
to the application. Aside from the low performance, is there a reason why
this would fail? And why oh why, history buffs, does the state after a
signal reception revert to vulnerable rather than ignore? Forgive me
if there is some good reason you all know and I would know too if I had
spent my requisit time on top of a mountain of Pdp-11s.
To anyone reading this and getting ideas, it really is true that you should
not use signals for IPC -- you will regret the attempt unless you correct
a few features in the kernal. But I wonder if the sematics are really so
unsuitable as to call it hitting a nail with a wrench. Seem more like
hitting a nail with a hammer which has a loose head piece that is designed
to fly off after one whack on the nail.
----GaryFostel----dvk@mi-cec.UUCP (Dan Klein) (09/19/83)
Clearly, the signalling mechanism currently in Unix is far from optimal for anything other than the most simpleminded IPC. The mailbox approach is reasonable, but tricky, since you need to have a way of passing the names of the mailbox (for which you need IPC already), or just making it an open file which gets transferred via exec. There is one advantage to signals which cannot be overlooked in this discussion: they have the ability to interrupt you. Pipes do not. Perhaps having a VMS style AST to interrupt you on file/terminal activity is the way to go. This way you get notice when a communicating process has something to say, or you can simply poll things. This makes useful programs (like multi-player interactive games) easy to write. They just do their real-time things until the player changes some state by issuing a command. (Sorry for the stream of consciousness...)
barmar@mit-eddie.UUCP (Barry Margolin) (09/20/83)
The mailbox approach is reasonable, but tricky, since you need to
have a way of passing the names of the mailbox (for which you
need IPC already), or just making it an open file which gets
transferred via exec.
If the two processes are brothers then you don't need IPC so much
because they could use a pipe. IPC is only necessary when the
creator of the processes did not expect them to communicate, as in
processes belonging to different users.
There is one advantage to signals which cannot be overlooked in
this discussion: they have the ability to interrupt you. Pipes
do not. Perhaps having a VMS style AST to interrupt you on
file/terminal activity is the way to go. This way you get notice
when a communicating process has something to say, or you can
simply poll things. This makes useful programs (like
multi-player interactive games) easy to write. They just do
their real-time things until the player changes some state by
issuing a command.
What you can do is combine signals with IPC. You use the IPC (or even
pipes) facility to transmit information, but you signal a process to
tell him that there is stuff in the queue that he should look at.
--
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmarsvr@wjh12.UUCP (Rosenthal) (09/20/83)
systems) have actually implemented VMS/RSX - style ASTs in such a way that they can be used as the basis for general-purpose IPC. It's the best way to write some kinds of programs (e.g. real-time data acquisition). They have a separate astpause function which waits for the process to receive an ast or times out after some arbitrary time. I'm finding that when combined with pipes or FIFOs you can devise very neat IPC schemes. Simon Rosenthal(!decvax!genrad!wjh12!svr)
svr@wjh12.UUCP (Rosenthal) (09/20/83)
(I'll try again -- last one got munged by inews) Masscomp (makers of MC68000 Unix- based laboratory computer systems) have actually implemented VMS/RSX - style ASTs in such a way that they can be used as the basis for general-purpose IPC. It's the best way to write some kinds of programs (e.g. real-time data acquisition). They have a separate astpause function which waits for the process to receive an ast or times out after some arbitrary time. I'm finding that when combined with pipes or FIFOs you can devise very neat IPC schemes. Simon Rosenthal(!decvax!genrad!wjh12!svr)
gwyn@brl-vld@sri-unix.UUCP (09/21/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> Signals have several bad properties for IPC: 1. They break "slow" (i.e. non-disk) i/o in progress (the Berkeley "cure" for this is worse than the disease); 2. They reset the signal-catching state to SIG_DFL before dispatching to a signal catcher (trying to fix this would break code that depends on this side-effect); 3. Multiple signals do not stack or block the sender. 4.2BSD is supposed to provide a more flexible signal scheme.
edhall@rand-unix@sri-unix.UUCP (09/22/83)
Signals as implemented in V7 UNIX have too may quirks for IPC, as I'm sure several messages will point out. But 4.1BSD fixes (?) the problem in its `jobs' library (see JOBS(3J) and SIGSYS(2J)) in the Berkeley manual). A mechanism is provided which allows further signals to be defered after the first occurance, avoiding the problem of V7's reset-to-default after signal. The ability is also provided to hold (rather than simply ignore) signals during critical sections. That all this works is illustrated by CSH, which simply sits in pause() and only calls wait() (actually wait3()) when it receives a special SIGCHLD signal indicating a status change in a child process. Note that dropping a signal would hang the shell! Much of the signal mechanism was re-worked in 4.1BSD to provide job- control. I don't know if it has changed again with 4.2... Compatability with the old signal scheme is provided by having a per-process flag which is set only when any of the new stuff is used. (Smells like a kludge, no?) -Ed Hall edhall@rand-unix decvax!randvax!edhall
preece@uicsl.UUCP (09/22/83)
#R:mi-cec:-15400:uicsl:12500010:000:688 uicsl!preece Sep 21 07:23:00 1983 IPC is only necessary when the creator of the processes did not expect them to communicate, as in processes belonging to different users. ---------- Surely you don't mean the first part of that sentence as written. A process isn't going to be much good with ANY kind of IPC method if it wasn't intended to use it. The need for IPC is to allow communication between processes operating independently, whether for the same or different creators, but the use of the communication medium must be thought out carefully in advance in any case. Each process must know exactly what kind of communication is to be expected and how to respond to it. scott preece pur-ee!uiucdcs!uicsl!preece
naz@sdcrdcf.UUCP (Norman Azadian) (09/22/83)
The author of the reference article suggested building a low-performance IPC using unix signal/kill routines. I thought the same thing many months ago and decided to build it for a project. My design had a "message switch" process which started up all the application processes with two pipes to each. There was a library of IPC routines that the application processes could use to make sending and receiving messages easy and straightforward. In one mode of operation, the "message switch" process spent all it's time looking for messages on it's input pipes (this is a star system) and routing them to the appropriate output pipes. The application processes had to poll their receive pipe similarly. More sophisticated versions involved signals to and from the "message switch". The signalling scheme worked well at low speeds, but started to fall apart as the message traffic increased. Signals seemed to just get lost in space. This was with a vax-11/780 running 4.1bsd. I still have the code if anybody is interested. I believe the strictly-polling mode works. NHA
barmar@mit-eddie.UUCP (Barry Margolin) (09/23/83)
This message is empty.
nrf@whuxlb.UUCP (09/24/83)
#R:ncsu:-233700:whuxlb:900024:000:505 whuxlb!nrf Sep 24 10:38:00 1983 Faced with porting a message-based system of 4 processes from UN*X 4.x+ on a 11/70 to Unix 3.0 on an 11/34, which couldn't fit messages into the kernal because of the address space limitations, I was able to emulate the message facility in a compatible fashion using NAMED PIPES. The only feature I didn't emulate was the limitation on message queue length, but that was not really a problem since UN*X buffers up to 10 blocks onto disk if necessary. N.R.Fildes, BTL-Whippany (marx-machines!whuxlb!nrf)