Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP
Path: utzoo!linus!decvax!genrad!mit-eddie!barmar
From: barmar@mit-eddie.UUCP (Barry Margolin)
Newsgroups: net.unix-wizards
Subject: Re: Unix IPC
Message-ID: <754@mit-eddie.UUCP>
Date: Mon, 19-Sep-83 23:50:29 EDT
Article-I.D.: mit-eddi.754
Posted: Mon Sep 19 23:50:29 1983
Date-Received: Tue, 20-Sep-83 21:09:21 EDT
References: <154@mi-cec.UUCP>
Organization: MIT, Cambridge, MA
Lines: 25


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