Path: utzoo!utgpu!water!watmath!clyde!rutgers!im4u!ut-sally!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: IPC (1): Ports & Messages
Message-ID: <8803170728.AA16296@cory.Berkeley.EDU>
Date: 17 Mar 88 07:28:47 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 22

:In article <1401@louie.udel.EDU>, rminnich@udel.EDU (Ron Minnich) writes:
:> 2) As for the message broker, make it a library, then we in effect
:>    have multiple copies running for each client ( i am thinking
:>    as opposed to having a 'port manager' task which will be 
>>    a bottleneck)
:
:A message manager would be a bottleneck. A port manager wouldn't be, since
:it's only accessed to get the port and to release it. However, Matt Dillon's
:adfe ports would allow you to put the port manager in a library relatively
:easily.

	One would put in the library any functions that would otherwise
take a large amount of code, should be in the library for future 
compatibility issues, or provide logical high level constructs.  You
ONLY get a bottleneck for things requiring sequencing (whether it is
in a library or not).

	So, for instance, the extended port structure which handles simple
id'ing and a reference count would be hidden by the functions in the library
that deal with it, allowing for future expansion.

					-Matt