Path: utzoo!mnetor!uunet!husc6!bloom-beacon!think!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: IPC: Messages (again)
Message-ID: <8803151957.AA11010@cory.Berkeley.EDU>
Date: 15 Mar 88 19:57:23 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 67

:ReplyMessages
:_____________
:
:Many want to insist that ALL messages should be replied, but this really
:doesn't work.  You can't always expect the client to still be around when

	You are out of your mind.  OF COURSE THE MESSAGES HAVE TO BE REPLIED!
I want to statically allocate my messages.  I want to know when the pointers
I passed are no longer being used.  If you insist that replying messages
would be wasteful, I would like to point out that one can set the replyport
to "call a function" instead of "signal a task", so the guy sending the message
has full control over whether he wants to handle replies or wants to just
FreeMem() the message.

	You are making that assumption that you have thought of everything
anyone will ever want to do.  That is a bad assumption to make.

	As far as the client going away before the message is replied.
Since the client (who sent the message) KNOWS it intends to go away, it
will AllocMem() the message AND replyport, and will turn of PA_SIGNAL when
it leaves... or use a 'standard' sink-null port which deallocates messages
automatically (via the function-call-on-reply mode you can stick ports in).

>My philosophy is to try and hammer out a protocol that won't prove
>restrictive for future applications and extensions, so I think we have to
>allow for the possibility that a client won't want its message back.  A
>server therefore must be prepared to deallocate that memory block if no
>ReplyPort is given.

	See above.  But what you described was *VERY* restrictive.

:A specially awkward case is the ln_Name field of a message.  If we use this
:as a pointer to an identifying string we could get a little stuck.  Unless
:we followed the cumbersome route of allocating space for the name string
:(when no doubt we would rather point directly to a string constant), the
:name would go away with the client.  For this reason I suggested that it
:probably was NOT a good idea to use this as a pointer, and that would leave
:it free as our ID word.  I was immediately flamed for this, so perhaps to
:keep everyone happy we should just ignore this field: anything it points
:to is not part of the message space (and may no longer exist).

	What you do is say "the ln_Name field is not used by the receiver
of the message, but rather is reserved for whatever purpose the client
wishes".

:Message status
:______________
:
:I touched on this in another article, but I include it here for
:completeness.  It's a good idea to keep the generic "outcome" report in a
:replied message separate from application specific status flags.  There are
:really very few possible outcomes, which I would flag as follows in the
:ln_Type byte:
:
:    NT_MESSAGE      --  as originally sent by the client
:    NT_REPLYMSG     --  normal reply after processing
:    NT_UNKNOWN      --  (= 0) the server couldn't handle this type
:    NT_NOSERVER     --  (new type = 0xFF) returned by a port broker that
:                        handles the message in lieu of an owner

	NO NO NO!  the ln_Type field should be used only for NT_MESSAGE
	and NT_REPLYMSG.  Take another byte of your precious message format
	for an error field.  How do you intend to atomically set the message
	type to NT_NOSERVER when ReplyMsg() automatically sticks an
	NT_REPLYMSG in the field???????  

				-Matt