Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!cbmvax!jesup
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: message ports seeing the future?
Message-ID: <21855@cbmvax.commodore.com>
Date: 23 May 91 22:29:13 GMT
Article-I.D.: cbmvax.21855
References: <24436@know.pws.bull.com> <21732@cbmvax.commodore.com> <2726@fornax.UUCP>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA
Lines: 70

In article <2726@fornax.UUCP> laughlin@lccr.UUCP (Bob Laughlin) writes:
>    This is mentioned in the 1.3 RKM's as well. On page 285 it says
>"It is possible to receive a signal for a port without a message being
>present yet." Could you elaborate on this?

	It's situation-dependant in most cases.  For example, you're
processing messages at a port.  A message comes in, you wake up (clearing
the signal bit), and process it.  While processing it another message
comes in, setting the signal bit again.  You loop back to GetMsg(), and
find a second message, and process it.  You then go and wait, and immediately
return since the signal is set already.  However, there are no messages in the
port.

	Another one: there's no guarantee when you allocate a signal that
it starts clear.

>I'm not sure
>what WaitPort() does with the sigbit but I suspect it does'nt clear it
>either since it only retrieves the first message.

	No, it clears it.  (Essentially it's do { Wait(portbit); msg =
first_message_in_list;} while (!msg); return msg;.)  NOTE: WaitPort
returns a pointer to the first message, but doesn't remove it from the
port.

>I can see how you could get into trouble by leaving a reply port's sigbit
>set by using WaitIO() or WaitPort() but my concern is what happens when
>you know the bit has been cleared with the Wait() function.

	Wait is guaranteed to clear it - but if other messages may come back
to the same port, or if it was set for some other reason (such as being set
when allocated), then you must handle the possibility.  It's possible to set
up a port to which only one message ever comes (and where you cleared the
signal bit first) such that the signal is a reliable indicator of a message
being available, but I recommend against doing this.  It's better to code
defensively, since you may one day make a modification that would remove
a required assumption.

>    What happens if another message is added to the reply queue while
>you're processing the messages there after Wait() returned? Say your
>process is swapped out between processing the 2nd and 3rd replied
>message.  Does the signal bit get set again but you GetMsg() the
>new message on the old Wait()?

	Yup.

>    In other words when Wait() returns after waiting for a sigbit is it
>possible for a message to NOT be in the reply port queue?

	Yup.

> I've been
>testing the GetMsg()'s in this situation and have yet to have one fail.

	Timing is everything in multi-process testing.  Code for correctness
and the timing becomes irrelevant.

>   If it is possible for Wait() to return thus waking your process with
>no message in the reply queue it seems to me that you are in big trouble
>if you need that message to proceed. You can't do another Wait() since
>the sigbit has been cleared.

	We most explicitly don't allow the signal to be set before the message
is available.  PutMsg/etc is protected by Enable and/or Forbid.

-- 
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
"No matter where you go, there you are."  - Buckaroo Banzai