Xref: utzoo comp.sys.amiga.tech:9 comp.sys.amiga:15674
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.tech,comp.sys.amiga
Subject: Re: IPC (1): Ports & Messages
Keywords: InterProgram Communication, tools
Message-ID: <7546@agate.BERKELEY.EDU>
Date: 9 Mar 88 10:56:49 GMT
References: <7409@agate.BERKELEY.EDU> <1401@louie.udel.EDU>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: pete@violet.berkeley.edu.UUCP ( Pete Goodeve )
Organization: University of California, Berkeley
Lines: 51

[This is a response to an article in comp.sys.amiga.tech.  Because of the
uncertain distribution of this group, I'm cross posting to comp.sys.amiga.
-- Note to Ron: maybe we'd better keep any further discussion over there
for now!]

In article <1401@louie.udel.EDU> rminnich@udel.EDU (Ron Minnich) writes:

> In article <7409@agate.BERKELEY.EDU> pete@violet.berkeley.edu () writes:
> >The rest of the structure should be filled in properly, too, and we should
> >be sure that the standard rules are followed.  (I presume -- but haven't
> >checked -- that PutMsg sets the ln_Type to NT_MESSAGE, and ReplyMsg sets it
> >to NT_REPLYMSG.  Anyone know for sure?)  The receiving program should be
>     I know for sure that it does not. I found that out the hard with
> internet.device, where i had to jam NT_MESSAGE into messages IN THE
> DRIVER, even though the messages had been PutMsg'ed.

Damn.  Oh well.  Thanks.  We'll just have to enforce the rules ourselves,
then.

>    Two thoughts:
> 1) Seems like we also need a 'port broker'. Isn't that function served
>    by PIPE:, or am i missing something fundamental? I.e. rather than
>    use ports, just use PIPE: which strikes me as being more reliable?
>    Or do we lose something valuable by not using ports?

I'm not sure I follow your line of reasoning there, but there are some
fundamental problems I see in basing everything on pipes: they're basically
byte serial, which is very inconvenient for structured data, and even more
important they involve buffering and therefore COPYING of data -- a lot of
overhead.  Messages on the other hand don't move -- they're just inserted
in a list, so making a lot of data available to another task can be very
fast.  For a general IPC scheme, I think we have to be concerned with
speed.

I'm not saying we should discard pipes: they're especially useful when the
data is normally serial-file based...  well, I don't need to tell you that:
this all started with "tools.. etc." didn't it...

> 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)

I agree totally.  At least in principle.  I went the port route because I
thought that the concept was clearer that way, but I'm sure a library is
the way to go in the long run.  For a start it removes all danger of the
FindPort hazard we've been talking about.  On the other hand, though, I'm
not sure that a manager process would in fact be a bottleneck: after all
this is a one-task-at-a-time machine really (sigh)!

                                            -- Pete --