Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu (Pete Goodeve)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Inter process communication
Message-ID: <1991Mar17.101503.13798@agate.berkeley.edu>
Date: 17 Mar 91 10:15:03 GMT
References: <1808@swrinde.nde.swri.edu> <12004@pasteur.Berkeley.EDU> <1991Mar15.185824.8200@jato.jpl.nasa.gov>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: University of California, Berkeley
Lines: 72


In  <1991Mar15.185824.8200@jato.jpl.nasa.gov> (15 Mar),
Jeff Dickson (jdickson@jato.jpl.nasa.gov) writes:
>In article <11854@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes:
|>
|> At any time thereafter, task4 can ShutIPCPort(port4), and port4 will no
|> longer accept *new* messages, although it will still be around....
>
>       Does that mean the message port never gets deleted?
>
The thing about ppIPC is that a Port doesn't "belong" to either the Server
or Clients using it.  It is managed by the library, and stays around just
as long as there are any references to it.  "Shutting" a port is a
convenience that lets the server handle any outstanding messages while
blocking any more from arriving, before finally dropping its own reference
to the port.

>       This is my two cents on how to implement an IPC system that is not
> plagued by the problems I believe to be in the IPC talked of above.

Nahh! ...NO problems.... (:-))

Seriously, though, I think ppIPC is covering exactly the points you are
worried about.  Go check out the docs on Fish #290.

>
>       1. Have a master IPC task that hands out message ports on request.
>          The call from the client will really send a request message to
>          the master. [....]
As I say, the ppipc.library does essentially precisely this (although it
is a resident library rather than a separate task).  Because it is a single
"common channel" it can manage the assignment (and deallocation) of ports
safely and easily.

>
>       2. [...] Messages that have arrived at a particular message port are
>          queued in a list that is only accessible off it. The memory con-
>          sumed is not dependant on the underlying task being present or
>          not. You couldn't simply disappear. You can't do that with alloc-
>          ated memory, open files, etc. You would have to at least relinguish
>          the message port. The master would set SigTask to itself and the
>          signal to some preallocated "catch all" signal. That way the master
>          could do clean up before deleting it. Also, if the message port
>          were to stick around, this way you could arrange for it to no
>          longer accept messages. Really the task that the message port
>          belonged to could not be sent a message, but the master could be.
>          It wouldn't reply, but it would delete them. The above could be
>          considered synonomous with ShutIPCPort(port4).
Again, this is the way ppipc works. Except that there is really no need to
have a "surrogate" process to handle messages for a departed task.  If the
task no longer exists, the message is simply blocked (PutIPCMessage fails)
and the sender disposes of it again.  There is, though, provision in the
system for a "Broker" that handles loading of the processes that service
particular ports, and -- if there is some reason for it -- this is perfectly
capable of assuming responsibility for orphan messages.

>
>       3. If the relinquished message port contains pointers to other
>          objects, then either the client has to deal with them before
>          dieing, or the master has to know them.
...Taken care of by the definition of the IPCMessage format.  Flags indicate
for example whether the data remains the property of the sender (and will
not be dumped until the message is replied) or is to be transferred to
the server.

>
>       This is merely speculative of how I would design an IPC system. I
>       am at my real job and don't have my manuals at hand.

Well, they MUST be good ideas... they're awfully close to mine (and others)!
(:-)) (:-))
                                        -- Pete --