Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ptsfa!ames!pasteur!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu
Newsgroups: comp.sys.amiga
Subject: Re: IPC - A proposal
Message-ID: <7490@agate.BERKELEY.EDU>
Date: 8 Mar 88 08:57:38 GMT
References: <5375@well.UUCP> <739@nuchat.UUCP> <7455@agate.BERKELEY.EDU> <2116@polya.STANFORD.EDU>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: pete@violet.berkeley.edu.UUCP ()
Organization: University of California, Berkeley
Lines: 36


In article <2116@polya.STANFORD.EDU> rokicki@polya.UUCP (Tomas G. Rokicki) writes:
>> [had to delete my original comments -- mailer objected to lack of novelty!]
>
>Nope, all code which sends a message to a public port which might be
>shut down should do a
>
>	[shows Forbid/FindPort/Permit sequence -- see "IPC (1):" article]
>
>Arguments are probably confused, but you get the idea.  Hold/Release
>is okay, except the Browser might need to abort due to some
>catastrophic problem when a Hold has been put on it.  Do the above,
>and everything's hunky-dory, except you have a FindPort() within
>Forbid()/Permit() . . .

Tom -- did you read my "IPC (1)..." posting?  That F/F/P sequence is
just what I'm trying to get away from.  For an IPC scheme we must do better
than that.  (I forgot to mention this part in my note to Peter, but it
is in my original posting:) Browser should also be able to send a 
-- universally recognized -- DISCONNECT message that will tell the
caller not to use that port address any more, and part of the standard
protocol is that the caller MUST recognize such a message.  Remember
that we're implicitly requiring that communication be two-way, and
the standard procedures we write should always be able to handle this.

>
>Oh, and give them a longword length if at all possible; I can see
>no reason to *limit* message length to 64K.  It's that kind of
>thinking that gave MSDOS 640K and TOS 40 folders.

But we're using an exec Message structure, and this already has a UWORD
for the length!  We aren't applying an absolute limit here, though:
just define a type of message for the job which has a pointer to the
data -- who wants to copy that much data into the message structure
anyway?
						-- Pete --