Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!bagate!dsinc!unix.cis.pitt.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!jato!jdickson
From: jdickson@jato.jpl.nasa.gov (Jeff Dickson)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Inter process communication
Message-ID: <1991Mar15.185824.8200@jato.jpl.nasa.gov>
Date: 15 Mar 91 18:58:24 GMT
References: <19579@cbmvax.commodore.com> <10708@dog.ee.lbl.gov> <11854@pasteur.Berkeley.EDU> <1808@swrinde.nde.swri.edu> <12004@pasteur.Berkeley.EDU>
Reply-To: jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 65

In article <12004@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes:
>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:
>
>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 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?
>
>
>Thanks Kent!
>David Navas                                   navas@cory.berkeley.edu

	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.

	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. The message will include the client's task id and
	   an allocated signal number. The master will construct the message
	   port, but it will live in the context of the client, because the
	   signal number belongs to the client and the constructed message
	   port SigTask field will be initialized to that of the client.

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

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

	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.

	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.

						Jeff

		P.S. Apologize if my way is illeagal. But I don't see how
	it could be.