Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!duke!unc!mcnc!ncsu!fostel
From: fostel@ncsu.UUCP
Newsgroups: net.unix-wizards
Subject: RE: UNIX IPC
Message-ID: <2337@ncsu.UUCP>
Date: Sun, 18-Sep-83 18:06:59 EDT
Article-I.D.: ncsu.2337
Posted: Sun Sep 18 18:06:59 1983
Date-Received: Mon, 19-Sep-83 01:04:32 EDT
Lines: 26



    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----