Xref: utzoo comp.sys.amiga:16174 comp.sys.amiga.tech:59 Path: utzoo!mnetor!uunet!nuchat!peter From: peter@nuchat.UUCP (Peter da Silva) Newsgroups: comp.sys.amiga,comp.sys.amiga.tech Subject: Re: IPC: Messages (again) Message-ID: <806@nuchat.UUCP> Date: 17 Mar 88 02:32:55 GMT References: <7685@agate.BERKELEY.EDU> Organization: Public Access - Houston, Tx Lines: 136 In article ... pete@violet.berkeley.edu (Pete Goodeve) writes: > 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 > the message has been processed. Yes you can. I do. 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. > More urgently (for those who think the previous scenarios too fanciful), if I don't think they're fanciful. I just think they're dangerous. > you are sending MIDI messages or some other time-critical type of data, the > last thing you want is to burden yourself with replying and handling > replies. This is a good reason for having them, though. 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). > It MUST of course have been obtained with AllocMem by the client. Things > are a lot simpler if the message block itself is the only memory involved; > then we can just use the mn_Length field (adjusted suitably) for FreeMem. > This is why I think we shouldn't always use pointers where they otherwise > might look appropriate. I don't think we can make any general rule here: > just be aware of the requirements of a particular application. This 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. Also, by requiring messages be contiguous you radically increase the amount of copying that's going on. > A specially awkward case is the ln_Name field of a message.... > we should just ignore this field: anything it points > to is not part of the message space (and may no longer exist). Good point. It's forgotten :->. > It has also been suggested that message contents shouldn't be changed > except for a status word, but again this is unnecessarily restricting the > ways a message might be used. After all, one of its main purposes is to > request and return data! A client should expect that any part of the > message data area may have been rewritten (meaningfully of course!) on > reply. I wasn't saying that things entries point to wouldn't be overwritten, just that the entry list itself be inviolate. After all, it might not be big enough for the reply. 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. For anything more complex than a status, the client should supply the server a port to send its data to. This can be the reply port (after all, the reply is an IPC message and won't be confused with any extra messages). > One of the major advantages of messages is that they require little > overhead to pass. We should therefore avoid formats that add to the > overhead unless they are particularly appropriate for that task. My > 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. > There's nothing at all inherently wrong with multiple chunks, but because > most applications won't need them I don't think they ought to be part of > the fundamental IPC message structure -- unnecessary overhead again. If > they are used in a particular format, the first part of the data section > should be a set of pointers to the individual blocks, so access is direct > rather than sequential. Just send a single Entry in a message, pointing to the data immediately after the message itself. Absolutely minimal overhead, and completely compatible. > If there are any I've left out, there's lots of spare codes, and no real > way any particular choice could conflict with other uses. Are you sure that this is safe? What if C= implements NT_NETWORK in Kickstart 1.7? > struct StdIPCMessage { > struct Message ipc_Msg; > ULONG ipc_ID; > ULONG ipc_Status; /* application specific */ > ULONG ipc_Func; /* specific nature of this message */ > SHORT ipc_Entries; /* number of items following */ > APTR ipc_Items[]; /* data items OR pointers to items > depending on the ID */ Why complicate things by adding this extra level of indirection? Making it "struct { ULONG ie_ID; void *ie_PTR; } ipc_Items[]" would speed things up, and allow programs to pick and choose what parts of the structure the dealt with. > /* Any data items pointed to will follow message AND be > included in the mn_Length */ > }; Why? Does this include RastPorts, BitMaps, etc...? This requirement will force copying of large structures. > Actually if you look carefully at Peter's Browser structure, although there > are a variable number of entries, the format for each action is strict > enough that you would know where everything was without searching. You could, but I'd rather keep the format general and intelligable. This might not seem a big deal with the Browser case, but what about more complex structures? After all, the internal IDs in IFF files aren't strictly necessary either... they sure make it easier to deal with lots of programs with slightly different requirements, though. > You > could do without the pointers in this case (so our only real disparity is > in the function and positioning of the ID words. Can we get together on > this Peter?) If the data items were something like IFF chunks, though, I > think the pointer scheme would be well worth the slight extra space. I don't see why you can't put the IDs in there. The overhead is minimal, and it allows you to add extra data. For example, what if I came up with a new version of thr Browser that handled messages that contained something more than just the names and ports... say I added an extra text item to each 'ADDT' message to allow you to specify the menu as well as the menu item for your message, and then allowed you to provide several name/port pairs. New programs could deal with the old browser (they'd just all show up under tools) and the new Browser could deal with old programs. -- -- 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*.