Path: utzoo!news-server.csri.toronto.edu!rutgers!cbmvax!bagate!dsinc!unix.cis.pitt.edu!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!pasteur!cory.Berkeley.EDU!navas
From: navas@cory.Berkeley.EDU (David C. Navas)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Inter process communication
Message-ID: <12004@pasteur.Berkeley.EDU>
Date: 15 Mar 91 05:06:08 GMT
References: <19579@cbmvax.commodore.com> <10708@dog.ee.lbl.gov> <11854@pasteur.Berkeley.EDU> <1808@swrinde.nde.swri.edu>
Sender: news@pasteur.Berkeley.EDU
Reply-To: navas@cory.Berkeley.EDU
Lines: 76

In article <1808@swrinde.nde.swri.edu> kent@swrinde.nde.swri.edu (Kent D. Polk) writes:
>In article <11854@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes:
>>and still doesn't
>>solve the disappearing ReplyMsg port, but I use it *always* instead of the
>>regular calls, because of the added protection they provide.
>>At least one other person on the net has used it in his scientific
>>application, but I'll let him discuss what he thinks about it...
>
>...Um...
>...Me?..

Why yes, how did you guess :) :)...

>At the risk of taxing the patience of those who keep seeing me talk
>about this, please forgive.

Nah, this is csa.p where such things live to be talked about :)

>I use PPIPC in server/client and peer/peer relationships in my data
>acq. system. I mainly use it to get around the "disappearing ReplyMsg
>port" problem in conjunction ...

Hmm, I think either we have a misunderstandment, a mistyping, or I have missed
a rather important part of PPIPC!!

It seems from your later statements that you are using PPIPC to avoid the
"disappearing port" problem, not the "disappearing ReplyPort" problem.

IN particular, I think you have the following (please forgive me if I get the
	PPIPC calls named incorrectly, it's been to long...):


	ServerList --> port1 --> port2 --> port3 --> port4 --->||

   Each port has been properly UsePort()'ed, and some time later:

	Task1:  ServeIPCPort(port1);
	Task2:  ServeIPCPort(port2);
	Task3:  ServeIPCPort(port3);
	Task4:  ServeIPCPort(port4);

   Now when you go to send a message you do a PutIPCMessage(port1, msg),
and if it succeeds, you await a reply, if not you try port2.  When you
receive a reply you try port2.  This process continues.

At any time thereafter, task4 can ShutIPCPort(port4), and port4 will no
longer accept *new* messages, although it will still be around....

The ReplyPort problem I have is this:

	Let's say that when you send a message off to port1, you *don't*
	await your response, and send off to port2, port3 and port4.  Now
	you shut yourself down.

	What do you do when with those messages when the ReplyMsg (really,
	the PutIPCMsg(msg->ipc_Msg.mn_ReplyPort, msg) ) fails?  Specifically,
	when TaskX tries to reply, the message *bounces* off the shut port.
	Do you delete the message?  What if the message has pointers in it --
	do you de-allocate those regions too?  How?


If you have developed a task-independent solution both Pete and myself would
be rather interested...  (of course, that's short of counting the number of
messages actually sent out and awaiting their reply, which under certain
circumstances might be quite difficult...)

>Kent Polk: Southwest Research Institute (512) 522-2882
>Internet : kent@swrinde.nde.swri.edu
>UUCP     : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent

Thanks Kent!


David Navas                                   navas@cory.berkeley.edu
"Oh, that's an Apple???  I though they just shot themselves in the head..."
[Also try c186br@holden, c260-ay@ara and c184-ap@torus]