Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: message ports seeing the future? Message-ID: Date: 29 May 91 01:27:55 GMT Article-I.D.: overload.dillon.8067 References: <24436@know.pws.bull.com> <21732@cbmvax.commodore.com> <2726@fornax.UUCP> <21855@cbmvax.commodore.com> Organization: Not an Organization Lines: 43 In article <21855@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <2726@fornax.UUCP> laughlin@lccr.UUCP (Bob Laughlin) writes: >... >>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. Uh, I don't think you can say that. WaitPort() does this: while (PortMsgListEmpty) { Wait(PortSignalMask) } return(FirstMessageOnPort) Thus, WaitPort() is NOT guarenteed to clear the signal bit. For this and other reasons (the one about looping on GetMsg() before going back to Wait() -- which you *MUST* do), you cannot depend on the signal bit being in any specific state except that it will be set when a message is sent to a port. Also note that this guarentees that WaitPort() does not *care* about the initial signal state when called, meaning you can safely call it at any point in your code without worrying about the signal state. -Matt >-- >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 -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA