Xref: utzoo comp.sys.amiga:16519 comp.sys.amiga.tech:95
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu (Pete Goodeve)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: IPC: Messages (again)
Message-ID: <7929@agate.BERKELEY.EDU>
Date: 23 Mar 88 10:38:24 GMT
References: <7685@agate.BERKELEY.EDU> <806@nuchat.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: pete@violet.berkeley.edu.UUCP (Pete Goodeve)
Organization: University of California, Berkeley
Lines: 141

Article 17273 of comp.sys.amiga:
Subject: Re: IPC: Messages (again)

In <806@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) responds to
a posting of mine quibbling with some of his IPC message format
suggestions.  My response to his response has to be essentially: Yes, yes
... and yes.  Most of my disagreement seems to have been the result of
a rather hasty reading (hence misunderstanding) of what he was saying --
er, sort of what I've been accusing other people of doing!  Sorry.

In fact there was some very hasty thinking going on, because the IPCEntry
structure pair of {ID,pointer} is exactly what I came round to thinking was
the correct solution, yet didn't see that that was precisely what he had
suggested!  Somehow I'd got the impression he wanted the data in line. Ah,
well -- I guess we're in agreement.

At one or two points, though, I have a little more clarification to make,
so let's go round one more time.


> ......... 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...]
>            ......                    So, let's define a message type
> that's exempt from this restriction. We'll call it a timing message. A timing
> message doesn't contain any data outside the message itself (no pointers), and
> it doesn't contain anything that requires special handling (locks, etc).

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.

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.

> .....
> >[AllocMem/FreeMem]
> ... isn't necessary nor sufficient. As I noted before, pointers aren't the
> only thing that require special handling. Locks, Ports, Handles, and so on
> can't be handled just by freeing the memory involved.

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


> .....
> Also, by requiring messages be contiguous you radically increase the amount
> of copying that's going on.

I've abandoned that suggestion.


> ....
> I wasn't saying that things entries point to wouldn't be overwritten, just

(Actually I think I was referring to an earlier posting of yours here.)


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


>  [I said: ...]
> > picture of the ideal message is a simple fixed structure that gives you
> > direct access to any item within it, and my reaction to a couple of the
> > recent proposals is that they rather violate this principle unnecessarily
> > by using multiple chunks that can only be reached by scanning from the
> > beginning.
>
> As an alternative you could send several messages, but this would have more
> overhead than scanning a single message. Since the Entries are an array, you
> don't have much overhead at all in scanning them.

Actually (aside from the fact that I misread your scheme) I was thinking
more of the IFF type structures some have suggested, where the only way to
get to a particular chunk is by traversing all those preceding it.


> [regarding adding ln_Type codes...]
> Are you sure that this is safe? What if C= implements NT_NETWORK in Kickstart
> 1.7?

My reason for considering it "safe" is that normally messages are messages
are messages, and so even if we did choose a code that conflicted, it
shouldn't ever find itself in a list of anything but messages.

Anyhow, it turns out I was misinformed, and PutMsg and GetMsg DO set
the ln_Type field, so our possibilities become highly limited.  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 said] ..........                        (so our only real disparity is
> > in the function and positioning of the ID words.  Can we get together on
> > this Peter?)

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) */
    };


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

                                            -- Pete --