Xref: utzoo comp.sys.amiga:16778 comp.sys.amiga.tech:122
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!tektronix!uunet!nuchat!peter
From: peter@nuchat.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: IPC: Messages (again)
Summary: Looking good... the Pete/Peter message standard comes together.
Message-ID: <864@nuchat.UUCP>
Date: 27 Mar 88 15:04:44 GMT
References: <7685@agate.BERKELEY.EDU> <806@nuchat.UUCP> <7929@agate.BERKELEY.EDU>
Organization: Public Access - Houston, Tx
Lines: 97

In article ... pete@violet.berkeley.edu (Pete Goodeve) writes:
  Me:
< > ......... Programs should not go away and leave things hanging.
< > If you need to do this, reply to the message after squirreling away the
< > data in the message.
< > .... [sneakily edited...]

Yeh, I'm talking about realtime messages, not dangerous ones. You're
dangerous, Maverick :->.

< Yes, this is really what I meant.  If there's any complexity in a message
< we should hope it can be replied.  On the other hand, I still claim that we
< will run into situations -- many of which will be discovered later,
< probably when we have just outlawed the possibility -- where the server,
< rather than the client, will have to handle the disposal of resources.

In fact my Browser message deals with one such situation. My solution, which
I see (by means of psychotic powers I can predict what you're going to say
next :->) you understand, is to have the server explicitly claim resources
it requires.

< I can also envisage situations where two applications will want to share a
< bitmap, say, and there will be no way to tell beforehand which will want
< to go away first (leaving the other to release it).  We may want a
< use-count on shared memory, too.

Tricky. Let's leave this particular problem for later.

< Point noted.  Isn't sufficient, anyway.  But on the other hand these types
< of entities (Locks, etc.) are even more likely to be "handed over" to the
< other application.  Your suggestion that the server control ownership by
< zeroing out pointers it has "taken over" probably covers things fairly
< well (except for "sharing" things -- see above).

Ah, proof of my psychotic abilities. Yes.

< >    ......             Also, you might get more than one reply to a given
< > message. For example, in my browser messages... if you send an ADDT message,
< > you will get a reply every time the user selects you from his tools menu.
< 
< Uh, do you mean that ONE message will get replied more than once? (AFTER
< it has been GetMsg'd but NOT PutMsg'd again??!)  I'll assume you don't mean
< that, but rather that you will get additional messages to your reply port.
< (Which you in turn will have to reply?)

Yes, I'm using the term "reply" a little loosely, here.

< I do still
< think that we should add a UnkmownMsg() reply procedure (which would set
< the type to NT_UNKNOWN) as a format-independent way of telling the client
< it's out of luck.  And there IS that mysterious type NT_FREEMSG... does
< anybody know what that was reserved for?  (I inquired at BADGE without
< success.)

I don't see why you want to overload data onto this channel. Would another
USHORT in the body of the message be too much to ask for?

< And as usual didn't make clear what I meant.  I was only referring to
< the different positioning of the main ID word which for generality I still
< think should be the first longword of the message, with the status
< following.  So, does this come close to complete agreement?
< 
< struct IPCEntry {
<     ULONG   IE_Id;  /* strictly determines meaning of data referenced */
<     ULONG   IE_Size;    /* size of data structure -- I think we need this */
<     void   *IE_Ptr; /* points to defined data structure (could be within
<                     message block if IE_Id says so) */
<     };

I wouldn't want to put it into the message block depending on ID. Matt
Dillon's point about not having to know the ID to pass a message
along is a valid one. I think that you're right... we need teh size (and
of course Matt's point requires it) Let's just let pointers be pointers,
and allocate this stuff together when needed.

< struct IPCMessage {
<     struct Message IPC_Msg;
<         /* ..ln_Name field should be NULL
<             ..ln_Type will be NT_MESSAGE, NT_REPLYMSG or NT_UNKNOWN
<             mn_Length will include IPC_Items array and any in-line data
<         */
<     ULONG   IPC_Type,   /* four character (or other) ID */
<             IPC_Status; /* type dependent return status */
<     USHORT  IPC_Itemcount;  /* should be enough, surely? */
<     struct  IPCEntry    IPC_Items[];
<     };

< (I've vacillated between "Entry" and "Item"... I prefer "Item" slightly, but
< whatever.)

OK, let's go with "Item". struct IPCItem and all. (that what you mean?)

<                                             -- Pete --
-- 
-- 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*.