Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!ll-xn!mit-eddie!bbn!rochester!udel!rminnich
From: rminnich@udel.EDU (Ron Minnich)
Newsgroups: comp.sys.amiga
Subject: Re: IPC - A proposal
Message-ID: <1427@louie.udel.EDU>
Date: 9 Mar 88 02:53:24 GMT
References: <5375@well.UUCP> <739@nuchat.UUCP> <7455@agate.BERKELEY.EDU> <2116@polya.STANFORD.EDU> <44626@sun.uucp>
Reply-To: rminnich@udel.EDU (Ron Minnich)
Organization: University of Delaware
Lines: 26

In article <44626@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
>In article <2116@polya.STANFORD.EDU> (Tomas G. Rokicki) writes:
>>                                                 ...  Do the above,
>> and everything's hunky-dory, except you have a FindPort() within
>> Forbid()/Permit() . . .
>
>Hmmm, the problem everyone is complaining about is the speed of doing
>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 :
   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. 
   This on second reading sounds like what a device-driver does!
I am real uncomfortable with the mechanisms proposed so far. Sounds
like we really need a 'port broker' that people talk to. Or something.
Are you all sure that we can't use something like PIPE: as a 
(higher level, not really RKM kind of ) port
broker? This scribbling into a port just bugs me somehow. 
   Its a start, anyway ... This is fun!

-- 
ron (rminnich@udel.edu)