Path: utzoo!mnetor!uunet!husc6!think!ames!pasteur!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu
Newsgroups: comp.sys.amiga
Subject: Re: IPC - A proposal
Message-ID: <7455@agate.BERKELEY.EDU>
Date: 7 Mar 88 08:12:41 GMT
References: <5375@well.UUCP> <739@nuchat.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: pete@violet.berkeley.edu.UUCP ()
Organization: University of California, Berkeley
Lines: 33




 peter@nuchat.UUCP (Peter da Silva) writes:

| The Browser Message will be of this form:
|
|         struct BrowserMessage {
|                 struct Message b_message;
|                 ULONG   b_id;   /* 'BRWS' */
|                 ULONG   b_len;  /* sizeof(struct BrowserMessage) - sizeof(struct Message) */
|                 ULONG   b_type; /* 'ADD ' or 'DEL ' */
|                 ULONG   b_lock; /* directory lock of file */
|                 char *b_name;   /* name of file */
|         };
|
| You loacte the port to send this message with FindPort("BROWSER");
|
| Any objections?

 A little teensy one... It looks almost exactly the sort of structure I'm
thinking of, except for the b_len field.  Is that really needed?  You have
to fill in the b_message.mn_Length slot anyway  (or you should, for
consistency with exec conventions).  The b_len field doesn't actually
conflict with my suggested convention, because the 'BRWS' ID is in the
right place -- it just seems superfluous, is all.

How about my other point -- that FindPort can be hazardous, if Browser
should somehow be shut down between a FindPort and PutMsg?  Would you
consider adding codes 'HOLD' and 'RLSE' to your 'ADD ' and 'DEL '?
(I avoided the word 'LOCK' for probably obvious reasons...)

                                            -- Pete --