Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!rice!titan!phil
From: phil@titan.rice.edu (William LeFebvre)
Newsgroups: comp.sys.amiga.tech
Subject: Re: VANILLAKEYS and various other things
Summary: You should Wait before GetMsg
Message-ID: <2159@kalliope.rice.edu>
Date: 18 Nov 88 15:57:37 GMT
References: <1732@scolex>
Sender: usenet@rice.edu
Reply-To: phil@Rice.edu (William LeFebvre)
Organization: Rice University, Houston
Lines: 44

In article <1732@scolex> brianm@sco.COM (Brian Moffet) writes:
>3) In the same program as #1, I poll a windows IDCMP message
>port using GetMsg(W->UserPort).  If I receive a message I will
>take some action.   This action may be to go to a subroutine 
>which does a Wait(1<<W->UserPort->mp_SigBit).
>When this happens, the wait will succeed when there is no new
>message.  It apparently sees that there was a message.  I do 
>ReplyMsg() properly, so I am not sure what is going on.  
>
>-=-=-=-=-sample code fragment-=-=-=-=-
>	while((mp = GetMsg(up)) == NULL);
>	ReplyMsg(mp);
>	Wait(1<<up->mp_SigBit);	/* This returns immediatly */

That program fragment seems improper to me.  I don't have my RKM handy
(being at school right now), but I would guess that GetMsg returns NULL if
there is no message available.  That while loop then is basically busy
waiting.  This is a big no-no in a multitasking environment.  The proper
way to do this is to Wait first, then GetMsg.  This will take care of your
problem (the signal gets reset by the wait and doesn't need to be reset by
the reply) and will also keep your program from busy waiting.

Now if you just want to poll the port via GetMsg, and do something else if
no message was there, then that's different:
=-=-=-=-=-sample code fragment-=-=-=-=-
if ((mp = GetMsg(up)) == NULL) {
   ... something else ...
} else {
   ReplyMsg(mp);
   Wait(1<<up->mp_SigBit);  /* ??? */
   ...
}
Without the RKM's, I can't recall how one would go about clearing the
signal.  Doing a Wait after the GetMsg seems wrong to me, but that may be
the way to do it (I think that it would be guaranteed not to block in that
instance).

In my example, replacing "if" with "while" would be okay, provided that
the body of the loop was actually doing something constructive.

			William LeFebvre
			Department of Computer Science
			Rice University
			<phil@Rice.edu>