Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!tut.cis.ohio-state.edu!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Ultimate Wait-GetMsg strategy (?)
Message-ID: <8902120748.AA14666@postgres.Berkeley.EDU>
Date: 12 Feb 89 07:48:57 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 112

:>	while (notquit) {
:>	    Wait(1 << win->UserPort->mp_SigBit);
:>	    while (mess = GetMsg(win->UserPort)) {
:>		/* process message */
:>		ReplyMsg(mess);
:>	    }
:>	}
:
:Equivalent, *except* that you have a wait at the top that's not guarded
:by a `while (GetMsg())' loop.  Fine, perhaps, depending on how you enter
:the loop and what operations you allow inside the loop (what those
:subroutines might do to the signals, you know) but conservative programming
:techniques never hurt anyone.

	P.S.  I suppose in my old age (@ 22) I have turned to making my
code aesthetically pleasing (in a logical sense) and intuitive.  Of course,
what one sees of one's own code is never what one sees of another's code or
another sees of one's own code.

	The initial condition (Wait before check) is valid 
because you have not ready anything from the port yet, and a re-entry 
condition would also be valid because you have read all pending messages
(and the next one that comes in will set the signal).

	I agree with you that, if one were using the IDCMP port for other
purposes one might have to be careful... maybe if you wanted to use it as
a sink for IO requests to (which is not unreasonable).  In that case I
would put the Wait() at the bottom, but it would have to be like this:

	while (notquit) {
	    while (mess = GetMsg(win->UserPort)) {
		/* process message */
		..
		case CLOSEWINDOW:
		    notquit = 0;
		    break;
		...

		ReplyMsg(mess);
	    }
	    if (notquit)
	        Wait(1 << win->UserPort->mp_SigBit);
	}

	Otherwise the user would have to hit the close gadget twice.

: Re my multiple-IDCMP example

:Not very fair; mask1 can dominate, causing problems later.  Something
:like
:
:int msgseen ;
:while (notquit) {
:   msgseen = 0 ;
:   if (msg = GetMsg(port1)) {
:      msgseen = 1 ;
:   }
:   if (msg = GetMsg(port2)) {
:      msgseen = 1 ;
:   }

	True, but only in rare circumstances.  In most cases problems due to
temporary domination will not materialize.

	What you outline as a solution would take quite a bit more overhead,
but a few small changes would accomplish the same thing with the same overhead
as the initial case.  Unfortunetly, the codes looks a bit more messy:

	mask = 0;
	while (notquit) {
	    while (mask) {
		if (mask & mask1) {
		    if (msg = GetMsg(port1)) {
			...
		    } else {
			mask &= ~mask1;
		    }
		}
		if (mask & mask2) {
		    ...
		}
	    }
	    if (notquit)
	        mask = Wait(mask1 | mask2 | mask3);
	}

	The overhead for an AND operation is much less than that for a 
GetMsg() operation, even if there is nothing to get.

:might work a little better.  Remember, GetMsg() is *very* quick if no
:messages are on the port.  And your mousemove's won't completely lock
:out your serial I/O.  (You can change any one of the above `if (msg...'
:to while's, for things that *need* processing with a fair minimal
:latency.)

	As far as MOUSEMOVEs go, I have learned a valuable lesson:

	always get ALL MOUSEMOVE messages and just execute/utilize the
last one.  You can get fancy and execute/utilize whenever you come upon
a button change as well.

	It would be nice if one could adjust the maximum mousemove message
rate in 1.4

:>				-Matt
:
:Sorry for the flaming tone of this article, Matt.  I just hate people
:cutting down other people's coding style like that.

	I apologize, but it looked horrible!  Never mind that it worked....

				-Matt