🚀 go-pugleaf

: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 */

	Completely wrong, the program will freeze!

	(1) You busy wait in the while(), GetMsg() does NOT block, but returns
	    NULL if no message is ready.  This in itself is a big no-no.

	(2) You process just a single message and then you Wait().  Contrary
	    to your comment, Wait() will NOT return immediately every time
	    and you can get into a lockout situation

	Example:  Intuition sends three messages to you.  This causes the 
proper signal bit to be set.  Your while ends and returns the first message
which is then replied.  you then Wait() which returns immediately and CLEARS
the signal bit.  You then loop up to the top and do the while() again.

	The while returns the second message, you reply, but now since the
signal bit is cleared, the Wait() waits forever even though there is a 
third intuition message waiting.  (actually, if intuition queues a fifth
message it will unstick, but by this time it has gotten N messages off
and will never process all of them).
	
	Your code counts on intuition sending messages one at a time, 
which it does not do... intuition might queue any number of messages 
before your process has a chance to process any of them!

			PROPER CODE

	while (notdone) {
	    Wait(1 << up->mp_SigBit);
	    while (msg = GetMsg(up)) {
		<process the message>
		ReplyMsg(msg);
	    }
	}
	CloseWindow(window);	/* automagically removes any yet-to-be
				   GetMsg()d messages before closing down */

	Note that here I process ALL messages before looping.  In this case,
the only possibility of possibly incorrect operation occurs if I get a new
message while processing previous messages.  The new message sets the
signal bit, but it is also handled by the while() loop, which means when
the for(;;) loops up Wait() will return immediately and go through a 
'dummy-pass' on the GetMsg() (GetMsg() will return NULL and we will go
and Wait() again, this time Wait() really will Wait!).

						-Matt