From: Digest To: "OS/2GenAu Digest" Date: Sun, 8 Aug 2004 00:01:09 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [os2genau_digest] No. 908 Reply-To: X-List-Unsubscribe: www.os2site.com/list/ ************************************************** Saturday 07 August 2004 Number 908 ************************************************** Subjects for today 1 Single message queue explination : Dennis Nolan 2 Re: Single message queue explination : Mike O'Connor 3 Re: Single message queue explination : freiherr at earthlink dot net 4 Re: Single message queue explination : Mike O'Connor **= Email 1 ==========================** Date: Sat, 07 Aug 2004 08:11:08 +1000 From: Dennis Nolan Subject: Single message queue explination Hi everyone I've just come across this perl of information which I thought some of you might be interested in to quote Time for yet another overlapping and/or conflicting explanation PM will only dispatch one hardware-based (i.e. keyboard or mouse) message at a time. Until the target thread has fully processed the current msg (i.e. called WinGetMsg() again) PM won't hand out the next one. OTOH, software-based msgs (i.e. everything else) will continue to be dispatched normally. That's why the UI may be locked up but your clock, CPU meter, etc. continue to update normally. If your thread sleeps, goes into a loop, or whatever while processing a mouse or keyboard msg, the UI will lock up immediately. However, if it does so while handling another type of msg, it may be a while before the problem becomes apparent. To demonstrate this, I wrote a test app consisting of a dialog with a single button. I moved the dialog to a corner of the screen, moved the mouse far away from it, then pressed Enter. Since the dialog had the focus, this activated the button which posted a WM_COMMAND to the dialog. Upon receipt of this software-based msg, the dialog beeped then went to sleep for two minutes. As long as I kept the mouse away from the dialog, the system continued to work normally. I could switch focus, open and close windows, etc. I was able to move another window over part of the dialog and then away again with no ill effect except that the dialog didn't repaint (as expected). However, as soon as I moved the mouse over my dialog, the game was over. The UI locked up and stayed that way until the two minutes were up & my dialog resumed msg processing. Hopefully, this will give you a finer-grained understanding of how the SIQ works, and perhaps, why sometimes just moving the mouse around provokes a lockup. I think that it is a very good definitive explination Regards Dennis. ---------------------------------------------------------------------------------- **= Email 2 ==========================** Date: Sat, 07 Aug 2004 16:11:13 +1000 From: Mike O'Connor Subject: Re: Single message queue explination Dennis Nolan wrote: > Hi everyone > > I've just come across this perl of information which I thought some of > you might be interested in > > to quote > > Time for yet another overlapping and/or conflicting explanation > PM will only dispatch one hardware-based (i.e. keyboard or mouse) > message at a time. > Until the target thread has fully processed the current msg (i.e. > called WinGetMsg() again) PM won't hand out the next one. > OTOH, software-based msgs (i.e. everything else) will continue to be > dispatched normally. > That's why the UI may be locked up but your clock, CPU meter, etc. > continue to update normally. > If your thread sleeps, goes into a loop, or whatever while processing > a mouse or keyboard msg, the UI will lock up immediately. > However, if it does so while handling another type of msg, it may be a > while before the problem becomes apparent. > To demonstrate this, I wrote a test app consisting of a dialog with a > single button. I moved the dialog to a corner of the screen, moved the > mouse far away from it, then pressed Enter. > Since the dialog had the focus, this activated the button which posted > a WM_COMMAND to the dialog. Upon receipt of this software-based msg, > the dialog beeped then went to sleep for two minutes. As long as I > kept the mouse away from the dialog, the system continued to work > normally. > I could switch focus, open and close windows, etc. > I was able to move another window over part of the dialog and then > away again with no ill effect except that the dialog didn't repaint > (as expected). > However, as soon as I moved the mouse over my dialog, the game was > over. The UI locked up and stayed that way until the two minutes were > up & my dialog resumed msg processing. > Hopefully, this will give you a finer-grained understanding of how the > SIQ works, and perhaps, why sometimes just moving the mouse around > provokes a lockup. > > I think that it is a very good definitive explination > > Regards > > Dennis. Hi Denis, Good stuff! :-) I reposted the textual contents of your message on the os2user and eCS-Technical lists at yahoogroups dot com Which I think explains well the occasional lockups that I encounter in my Mozilla-based browser [almost never in the mail component of IWB] - actually had one earlier which generated the following entry in popuplog.os2: 08-07-2004 01:03:38 SYS3170 PID 0049 TID 0001 Slot 0064 F:\OS2WEB\OS2WEB.EXE c0010001 1c03c491 EAX=3b510e00 EBX=00da6230 ECX=3b510000 EDX=04700730 ESI=00000000 EDI=00000000 DS=0053 DSACC=f0f3 DSLIM=ffffffff ES=0053 ESACC=f0f3 ESLIM=ffffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:155b5ff8 CSACC=f0df CSLIM=ffffffff SS:ESP=0053:001418cc SSACC=f0f3 SSLIM=ffffffff EBP=00141904 FLG=00212206 DOSCALL1.DLL 0003:0000c491 Lockups I experience only ever seem to occur whilst I'm in the Browser - and in conjunction with one mouse action rapidly following the previous one. -- Regards, Mike Failed the exam for -------------------- MCSE - Minesweeper Consultant and Solitaire Expert -------------------- [ISP blocks *.exe, *.cmd, *.bat, *.reg attachments] [Please use zipped versions of above] ---------------------------------------------------------------------------------- **= Email 3 ==========================** Date: Sat, 07 Aug 2004 04:07:49 -0400 From: freiherr at earthlink dot net Subject: Re: Single message queue explination On 08/07/04 at 04:11 PM, Mike O'Connor wrote: >IWB] - actually had one earlier which generated the following entry >in popuplog.os2: > 08-07-2004 01:03:38 SYS3170 PID 0049 TID 0001 Slot 0064 > F:\OS2WEB\OS2WEB.EXE > c0010001 > 1c03c491 > EAX=3b510e00 EBX=00da6230 ECX=3b510000 EDX=04700730 > ESI=00000000 EDI=00000000 > DS=0053 DSACC=f0f3 DSLIM=ffffffff > ES=0053 ESACC=f0f3 ESLIM=ffffffff > FS=150b FSACC=00f3 FSLIM=00000030 > GS=0000 GSACC=**** GSLIM=******** > CS:EIP=005b:155b5ff8 CSACC=f0df CSLIM=ffffffff > SS:ESP=0053:001418cc SSACC=f0f3 SSLIM=ffffffff > EBP=00141904 FLG=00212206 > DOSCALL1.DLL 0003:0000c491 Had similar, for example: --- 02-21-2004 05:28:02 SYS3170 PID 0046 TID 0001 Slot 007c C:\PROGRAMS\BROWSER\OS2WEB.EXE c0010001 1c03c4a1 EAX=01d09bb0 EBX=74726f73 ECX=74726f73 EDX=00000008 ESI=00000000 EDI=00000000 DS=0053 DSACC=f0f3 DSLIM=ffffffff ES=0053 ESACC=f0f3 ESLIM=ffffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:16de603c CSACC=f0df CSLIM=ffffffff SS:ESP=0053:0014191c SSACC=f0f3 SSLIM=ffffffff EBP=00141954 FLG=00212206 DOSCALL1.DLL 0003:0000c4a1 ---- It's also happened here with PGP, for example. ---- 05-08-2004 19:45:44 SYS3170 PID 0031 TID 0001 Slot 0071 D:\CRYPTO\PGP\PGPK.EXE c0010003 1c025df9 P1=00000003 P2=XXXXXXXX P3=XXXXXXXX P4=XXXXXXXX EAX=1e4a6d40 EBX=00000000 ECX=0000000a EDX=0287f380 ESI=00000000 EDI=1e4a6d40 DS=0053 DSACC=f0f3 DSLIM=ffffffff ES=0053 ESACC=f0f3 ESLIM=ffffffff FS=150b FSACC=00f3 FSLIM=00000030 GS=0000 GSACC=**** GSLIM=******** CS:EIP=005b:1e4a6d8b CSACC=f0df CSLIM=ffffffff SS:ESP=0053:0287f148 SSACC=f0f3 SSLIM=ffffffff EBP=0287f364 FLG=00012246 DOSCALL1.DLL 0002:00005df9 --- >Lockups I experience only ever seem to occur whilst I'm in the >Browser - and in conjunction with one mouse action rapidly following >the previous one. If have other stuff going on, I go away for a while and make some coffee, and eventually, things return to normal. If I don't want to wait, well CAD immediatly resolves the matter. Regards, Eric Schilke Copyright (c) 2004. All rights reserved. ---------------------------------------------------------------------------------- **= Email 4 ==========================** Date: Sat, 07 Aug 2004 19:45:27 +1000 From: Mike O'Connor Subject: Re: Single message queue explination freiherr at earthlink dot net wrote: >On 08/07/04 at 04:11 PM, Mike O'Connor wrote: > >>IWB] - actually had one earlier which generated the following entry >>in popuplog.os2: >> >Had similar, for example: > >--- >02-21-2004 05:28:02 SYS3170 PID 0046 TID 0001 Slot 007c >C:\PROGRAMS\BROWSER\OS2WEB.EXE >c0010001 >1c03c4a1 > > >---- >It's also happened here with PGP > > >>Lockups I experience only ever seem to occur whilst I'm in the >>Browser - and in conjunction with one mouse action rapidly following >>the previous one. >> >> >> >If have other stuff going on, I go away for a while and make some >coffee, and eventually, things return to normal. If I don't want to >wait, well CAD immediatly resolves the matter. > >Regards, >Eric Schilke > > Hi Eric, Yes I've learnt not to try too hard to get it to come back [CTRL-ESC a few times : never successful] - that ends up with being unable to do a clean CAD - with subsequent bad CHKDSK - it always happens at an inappropriate time! :-( -- Regards, Mike Failed the exam for -------------------- MCSE - Minesweeper Consultant and Solitaire Expert -------------------- [ISP blocks *.exe, *.cmd, *.bat, *.reg attachments] [Please use zipped versions of above] ----------------------------------------------------------------------------------