Path: utzoo!mnetor!uunet!nuchat!peter
From: peter@nuchat.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga
Subject: Re: IPC (1): Ports & Messages
Message-ID: <753@nuchat.UUCP>
Date: 9 Mar 88 02:44:38 GMT
References: <7412@agate.BERKELEY.EDU>
Organization: Public Access - Houston, Tx
Lines: 54
Keywords: InterProgram Communication, tools
Summary: flak

In article ... pete@violet.berkeley.edu ( Pete Goodeve ) writes:
> By implication we have two ports, "his_port" and the reply port of the
> first program.  This should be all we need for two-way communication, as
> long as the reply port is prepared to handle messages other than replies.
> I don't see any difficulties here, and we don't want more ports around than
> we need.

I don't like the idea of using the replyport for anything but reply messages.
I think there's enough semantic confusion already in the system to add more.

> There's one other thing to look at first, and that's the format and content
> of the messages being passed around.

Well, a lot of messages could be handled by means of specific structures
designed by the authors of the server programs, but here's some idea for some
ids. I think it's a good representative sample, but you all will likely
disagree:

	'FILE'	followed by a directory lock and a character pointer.
	'CSTR'	followed by a pointer to a C string.
	'BSTR'	followed by a pointer to a BCPL string.
	'PORT'	followed by a message port.
	'FORM'	followed by *a pointer to* an IFF FORM.
		Making it a pointer shouldn't cause anyone any problems,
		and should make it easier to pack stuff into a message.
	'CAT '
	'LIST'	followed by a pointer to IFF CAT or LIST
	'MORE'	followed by a byte count and a pointer to another structure
		of this type, that many bytes long.
	'ARGV'	followed by a pointer to a UNIX-style argument vector.
	'STRT'	followed by a pointer to a workbench startup message.
	'WIN '	followed by a pointer to a window structure.
	'RAST'	followed by a pointer to a rastport.

	And so on. Making all this stuff pointers should cut down on
copying, and speed things up. All parts of a message have to be MEMF_PUBLIC,
of course.

	I don't think there's any need for EA's "MakeID" macro in this. Long
characters should do fine... it's all going to be on one processor, anyway.

> The receiving program should be
> able to assume that if mn_Reply is NULL it should dispose of the message's
> memory when done; if it is non-zero, of course, the message MUST be
> replied (possibly with data and/or ID changed).

I like the simplicity and security you get if you always reply to a message
on its reply port. The only thing changed in the reply should be the status
word. Yeh, there should be a status word in the structure somewhere, perhaps
immediately before or after the ID.
-- 
-- a clone of Peter (have you hugged your wolf today) da Silva  `-_-'
-- normally  ...!hoptoad!academ!uhnix1!sugar!peter                U
-- Disclaimer: These aren't mere opinions... these are *values*.