Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!pasteur!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu
Newsgroups: comp.sys.amiga
Subject: Re: IPC - A proposal
Message-ID: <7544@agate.BERKELEY.EDU>
Date: 9 Mar 88 10:43:40 GMT
References: <5375@well.UUCP> <739@nuchat.UUCP> <7455@agate.BERKELEY.EDU> <2116@polya.STANFORD.EDU> <44626@sun.uucp> <1427@louie.udel.EDU>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: pete@violet.berkeley.edu.UUCP ( Pete Goodeve )
Organization: University of California, Berkeley
Lines: 74


[My apologies if this message appears twice anywhere on the net.  My first
sending seems to have been eaten again ... at least it never appeared here.]


A couple of people have had suggestions regarding the FindPort Hazard
problem:

cmcmanis%pepper@Sun.COM (Chuck McManis) proposes:

>....
> a FindPort() which takes to long. Maybe what we need instead is a
> way of checking to see that a port we originally got was still valid
> and then encased the destruction of the port and sending to the port
> in F/P pairs. As an illustration :
> [.....omitted]
> Note that the NewDeletePort() would scribble on the port in some way to make
> it appear invalid (nulling out the memory would be sufficient) The the client
> task knows that port is now invalid and won't send to it. Then the server
> sends replies to all the messages that were queued. And exits. If all of the


and from rminnich@udel.EDU (Ron Minnich):

>    Or  maybe the following:
> a "reliable ports" add-on. When you want to use a reliable port you
> register as a user. Result is that a link-count gets incremented.
> When you are done, you say so, and when link-count goes to zero,
> then port goes away.
>.....
>    Its a start, anyway ... This is fun!

Yeah, ain't it?

I like Chuck's proposal best so far.  It's big advantage is that unlike
both Ron's and my schemes it doesn't need a cooperating client. (And I
don't think we want a port to go away when its use count goes to zero;
after all, it's initially zero until someone uses it!  Anyway, the server
might be a long term resident...)

My concept of lock and release messages would work for "server abort"
conditions if a client always checked ALL messages waiting on its reply
port (one of which might be a "bye-bye" from the server) BEFORE sending
more to the server port.  Alternatively the server whould have to wait  for
replies to its abort message from all its clients before shutting down.
BTW the server about to abort should do a RemPort first of all, to prevent
any NEW clients accessing the port by name;  the port is still valid to
those processes who know its address, so all current conversations can be
brought nicely to a close.

So my scheme is hazard proof providing all clients obey the rules, but one
which forgot to release, or didn't respond properly to an abort, could
really screw things up.  Chuck's suggestion -- though it does need the
client to use the proper calls ( which I assume would be encapsulated in
standard procedures as the sequence is always the same) -- avoids the
handshake sequence, and reduces the number of messages slightly.  My only
worry is the remote possibility of, say, the system planting ANOTHER port
in exactly the same place, so the ValidPort() call wouldn't catch anything.

How about this, though?  A valid public port always has a name, therefore
it has a specific pointer in its name field.  If ValidPort() checks on
this, there is essentially no way it can make an error (unless a subsequent
program planted a pointer to an identically-addressed data item in the same
place!).  An aborting server does a RemPort, then zeroes the name pointer
to prevent further messages.

Of course ValidPort would need an extra argument (the value of the name 
pointer -- obtained at the time of the original FindPort) so that it could 
actually make the check!


We're making progress...

                                        -- Pete --