1. [Win32Lib] w32HIdle eating up CPU time
Hello Derek,
perhaps you have fixed this in 0.58.2...
With 0.58, even a simple single window win32lib
application, when deactived (swiched to another app)
eats up all avaible CPU time, and usually locks up.
(I have WinXP) Same application coded using API directly or with
older win32lib, take up 0-1% CPU time. I think the reason is w32HIdle.
If I comment-out the following lines in eventLoop(), CPU usage
is 0-1% again :
-- while w32Func(xGetQueueStatus, {QS_ALLEVENTS}) = 0 do
-- lTock += 1
-- if sequence(invokeHandler(Screen, w32HIdle, {lTock, msg})) then
-- lTock = -1
-- exit
-- end if
-- end while
-- if lTock >= 0 then
getRC = w32Func( xGetMessage, { msg, hWnd, 0, 0 } )
if getRC = 0
or getRC = -1 then
exit
end if
-- if lTock > 0 then
-- VOID = invokeHandler(Screen, w32HIdle, {-1, msg})
-- end if
-- end if
I guess something is wrong with GetQueueStatus() usage.
WINAPI says : "For this reason, the return value from GetQueueStatus
should be considered only a hint as to whether GetMessage or PeekMessage
should be called."
If there is no way to get around this, I can live without w32HIdle...
Regards,
Martin
2. Re: [Win32Lib] w32HIdle eating up CPU time
----- Original Message -----
From: "Martin Stachon" <martin.stachon at worldonline.cz>
To: "EUforum" <EUforum at topica.com>
Subject: [Win32Lib] w32HIdle eating up CPU time
>
> Hello Derek,
> perhaps you have fixed this in 0.58.2...
>
> With 0.58, even a simple single window win32lib
> application, when deactived (swiched to another app)
> eats up all avaible CPU time, and usually locks up.
> (I have WinXP) Same application coded using API directly or with
> older win32lib, take up 0-1% CPU time. I think the reason is w32HIdle.
> If I comment-out the following lines in eventLoop(), CPU usage
> is 0-1% again :
>
> -- while w32Func(xGetQueueStatus, {QS_ALLEVENTS}) = 0 do
> -- lTock += 1
> -- if sequence(invokeHandler(Screen, w32HIdle, {lTock, msg}))
then
> -- lTock = -1
> -- exit
> -- end if
> -- end while
>
> -- if lTock >= 0 then
> getRC = w32Func( xGetMessage, { msg, hWnd, 0, 0 } )
> if getRC = 0
> or getRC = -1 then
> exit
> end if
> -- if lTock > 0 then
> -- VOID = invokeHandler(Screen, w32HIdle, {-1, msg})
> -- end if
> -- end if
>
> I guess something is wrong with GetQueueStatus() usage.
> WINAPI says : "For this reason, the return value from GetQueueStatus
> should be considered only a hint as to whether GetMessage or PeekMessage
> should be called."
> If there is no way to get around this, I can live without w32HIdle...
Firstly, 100% CPU is not a bad thing, so long as its not slowing other apps
down.
But anyhow, I've changed it now so that initially the w32HIdle event never
happens (that is the library does not do idle checking). If your application
needs to do this, it will have to call setIdle(True) first. You can always
setIdle(False) to turn it off again.
BTW, thanks for the bug fix in bkgnd16.exw
----------------
cheers,
Derek Parnell
3. Re: [Win32Lib] w32HIdle eating up CPU time
Derek wrote:
> Firstly, 100% CPU is not a bad thing, so long as its not slowing other apps
> down.
It does slow down other apps. I am getting choppy music playback, although
the player (Buzz) normally uses 5-8% CPU time. I guess this happens when
the player needs some more CPU time (filling buffer), but EXW is occupying
all remaing CPU time and OS must reschedule....
Also, 100% CPU usage might be a problem for those wanting to keep their CPUs
cool or save energy. I have CPU usage always 100% (Seti@home - check Euphoria
Programming Language team), but notebook owners do not want to. Modern CPUs
(Pentium MMX)
have 'hlt' instruction that can be used to turn off the CPU for a cycle and thus
cooling it down and saving energy. (The OS must support it - generate 'hlt' in
idle
loop - Linux 2.4 and perhaps Win2000) Some mobile CPUs can also slow down its
working frequency (Transmeta) according to CPU usage.
> But anyhow, I've changed it now so that initially the w32HIdle event never
> happens (that is the library does not do idle checking). If your application
> needs to do this, it will have to call setIdle(True) first. You can always
> setIdle(False) to turn it off again.
That is good for me. Probably the best solution would be to create a separate
w32HIdle thread with the lowest possible priority. But that is not possible with
Eu...
> BTW, thanks for the bug fix in bkgnd16.exw
Regards,
Martin
