🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #8416

Re: IPC: Messages (again) [+ -- Oopsie.]

#8416
From: Peter da Silva
Date: Thu, 07 Apr 1988 02:39
112 lines
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!peter
References: <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