Xref: utzoo comp.sys.amiga:15814 comp.sys.amiga.tech:17
Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!oliveb!sun!pepper!cmcmanis
From: cmcmanis%pepper@Sun.COM (Chuck McManis)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: IPC: Safe Ports (in any Storm?)
Message-ID: <45029@sun.uucp>
Date: 10 Mar 88 21:42:47 GMT
References: <5375@well.UUCP> <739@nuchat.UUCP> <7455@agate.BERKELEY.EDU> <2116@polya.STANFORD.EDU> <44626@sun.uucp> <7574@agate.BERKELEY.EDU>
Sender: news@sun.uucp
Reply-To: cmcmanis@sun.UUCP (Chuck McManis)
Organization: Sun Microsystems, Mountain View
Lines: 31
Keywords: InterProgram Communication, message, port, FindPort

[Well, I like it :-) ]
In article <7574@agate.BERKELEY.EDU> ( Pete Goodeve ) writes:
> It then can send its messages freely via the PutIPL call.  If the port
> happens to have been closed, the call will return FALSE; the client must
> always look for this, naturally, or it may wait for a reply forever.

Well, on FALSE return it could fake the reply as well as return FALSE
but that may be a bit exotic. How about change the mn_Type to LONELY_MSG
or something to indicate the client attempted to send it to a closed port?

> If we wanted, we could use this technique on a reply port too.  In this
> case the name would usually be a PRIVATE one (though I can't see any reason
> a reply port couldn't also be used as a public port).  The server would
> store the key away in an IPLink, and reply through a ReplyIPL() procedure
> analogous to PutIPL(), though it wouldn't use ConnectIPL().

Things stay much simpler when you have distinct client/server relationships.
If you want bi-directional asynchrounous communication you should be required
to act as both a server and a client. If you are going to make these things
really asyncronous bidirectional links you might as well implement "streams"
right now no? Which brings up an interesting question, AT&T streams let you
'push' a 'module' onto a stream, essentially injecting itself into the 
message flow. Would such a capability be useful for our IPC links? It
means messages would flow through 'n' message ports but it would be nice
to put say a filter in the message stream that dumped messages that you
didn't want to deal with.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.