Article View: comp.sys.amiga.tech
Article #8416Re: IPC: Messages (again) [+ -- Oopsie.]
From: Peter da Silva
Date: Thu, 07 Apr 1988 02:39
Date: Thu, 07 Apr 1988 02:39
112 lines
4815 bytes
4815 bytes
In article ... pete@violet.berkeley.edu (Pete Goodeve) writes:
> Responding to two of Peter da Silva's messages at once...
> From <864@nuchat.UUCP>:
> This was part of my fight to retrofit to other-format messages. I guess
> I've retired from that particular fray... We'll just reserve a bit or two
> in the IPC_Status field.
I like dis game, too.
> Agreed. My original thoughts were to have the ID control the format, as it
> does in IFF, but that becomes impractical when you take all the points Matt
> and other people have raised into account. See below for more...
> > OK, let's go with "Item". struct IPCItem and all. (that what you mean?)
> Yaay!! [jumps up and down in high glee...] Nynhh Hynhh.. I like dis game!
Are you a Goon Show fan, too?
(I talk to the trees, that's why they put me away)
> From <1771@sugar.UUCP>:
> > In my last IPC message I said that only pointers should go in the pointer
> > field of the IPCItem structure. That was totally bogus... you should be
> > able to put RastPorts, Locks, anything in there.
> ^^^^^^ that'll fit into a longword I assume..
Yeh, anything that will fit in a longword.
> A good thought, but does it go far enough? The problem seems to me that
> the server may need -- so far! -- at least three items of information about
> an item:
> 1) "You (the server) can take responsibility for this item, and free it
> when you're done"
Good point.
> 2) "The contents of this item may be transmitted elsewhere" (i.e. not a
> lock etc.)
> 3) "This item is included in the mn_Length" (maybe this could be
> flagged by a size field of zero, but there's always the chance we
> might like the size for some other purpose).
No, I wouldn't want to flag this with a size feild of zero, because the message
might want to be disassembled and reassembled on the other side of the gateway.
> These are pretty independent. One item might be a port structure, say,
> that could be passed to another process but not down a network; or a buffer
> could be transmittable, but kept by the client. I think IE_Size==0 should
> be reserved to indicate that the item is NOT a pointer.
At least that it's not an explicit pointer to something with a known size.
After all, the size of a SimpleRefresh layer can vary widely, and BPTRs are
still pointers. (yeh, I'm picking nits. Wanna make something of it?)
> Looks like we're forced into YAFF (Yet Another Bloody Field) in each item
YABF, don't you mean? :->
> struct IPCItem {
> ULONG IE_Id; /* strictly determines meaning of data referenced */
> ULONG IE_Flags;
> 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_Flags says so) */
> }; |
\_ Shouldn't this column be an 'I' for 'Item' now?
> /* Flags set by client (tentative, natch...): */
> #define IPC_IE_TRANSFER 0x08000000
> #define IPC_IE_NETWORK 0x04000000
> #define IPC_IE_INMESSAGE 0x02000000
> /* Flag returned by server (ditto): */
> #define IPC_IE_NOTKNOWN 0x80000000
#define IPC_IE_STOLEN 0x40000000
> I actually have NO suggested changes to the previous message structure...!
Wow.
> > -- a clone of Peter (have you hugged your wolf today) da Silva `-_-'
> ^^^^^ how many of these do you have? There's a Peter daSilva (sic)
> doing some good photo work for the campus newsrag. (If I had a
> DigiView, I'd send you a sample...) ]
Not one of mine, man. Here are my clones:
nuchat : ...!uunet!nuchat
| ...!hoptoad!academ!uhnix1!!nuchat
sugar : nuchat!sugar
| ...!hoptoad!academ!uhnix1!sugar
argent : nuchat!argent
| sugar!argent
nuchat!peter <-- clone #1.
sugar!peter <-- true name.
argent!peter <-- my amiga, with uupc.
sugar!ficc!peter <-- business wetware only.
...!seismo!ucmhou!peter <-- I think.
--
-- 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*.
Technical Details
Message-ID:
<895@nuchat.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!uunet!nuchat!peterReferences:
<7685@agate.BERKELEY.EDU> <806@nuchat.UUCP> <7929@agate.BERKELEY.EDU> <8250@agate.BERKELEY.EDU>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!mnetor!uunet!nuchat!peter From: peter@nuchat.UUCP (Peter da Silva) Newsgroups: comp.sys.amiga.tech,comp.sys.amiga Subject: Re: IPC: Messages (again) [+ -- Oopsie.] Message-ID: <895@nuchat.UUCP> Date: 7 Apr 88 02:39:55 GMT References: <7685@agate.BERKELEY.EDU> <806@nuchat.UUCP> <7929@agate.BERKELEY.EDU> <8250@agate.BERKELEY.EDU> Organization: Public Access - Houston, Tx Lines: 112 Keywords: IPC Message Format