Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!fornax!laughlin
From: laughlin@fornax.UUCP (Bob Laughlin)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: message ports seeing the future?
Message-ID: <2726@fornax.UUCP>
Date: 21 May 91 01:58:56 GMT
References: <24436@know.pws.bull.com> <21732@cbmvax.commodore.com>
Reply-To: laughlin@lccr.UUCP (Bob Laughlin)
Organization: School of Computing Science, Simon Fraser University
Lines: 56

In article <21732@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
#In article <24436@know.pws.bull.com> pmiller@vttcf.cc.vt.edu (Paul Miller) writes:
##However, now (and this is untested outside of the application I'm using the
##module in), when I tell the task to wait on a particular section, my app gets
##signalled BEFORE the cycles actually complete. This obviously screws up the

#	Hmmm.  It's hard to have any reasonable ideas without seeing some of
#the code, but in general I'd say you should check that you're not relying
#on the port signal to always mean that a message is available in the port.
#There are several ways (particularily with device IO, but ways exist with
#all ports) that signals can be left set after processing messages - you must
#handle the no-messages in port case correctly.

    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? I understand that retrieving
a message from a reply port with WaitIO() does not clear the ports sigbit,
and it should'nt since there may be other messages there. 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. I also know that
the Wait() function DOES clear the signal bits it is waiting on and you
are expected to GetMsg() all the messages queued up after it returns.
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.

    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()?

    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? I've been
testing the GetMsg()'s in this situation and have yet to have one fail.
I could see this arising if the device driver or Exec sets the signal
bit before queueing up the message at the reply port but I would have
thought these operations would be in the reverse order or Forbid() /
Permit()'ed. The scenerio described in the previous paragraph would
create the problem as well.

   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. I suppose you could do a WaitIO() on a
particular message(?), or---god forbid---a busy wait for the message
to get attached to the reply port? I'm talking about a situation where
you KNOW an IO message has been sent out and NOT previously retrieved
from the reply port.

   This situation has not occurred in several months of testing
for a failed GetMsg() following a Wait(). Is it possible or
am I misunderstanding that cautionary note in the RKMs?
-- 
 Bob Laughlin  laughlin@cs.sfu.ca