OpenEuphoria

RE: [WIN] sleep(0) tests

• Posted by Matthew Lewis <matthewwalkerlewis at YAHOO.COM> May 31, 2001
• 513 views

> -----Original Message-----
> From: gertie at ad-tek.net [mailto:gertie at ad-tek.net]
 
> What happens to a proper windoze application if an event 
> happens during a sleep(x), 
> and the Eu app has the appropriate routine_id() code to reply to it? 

It looks like Eu doesn't do anything while sleeping, so events just pile up
in the queue (except for timer fires, which go away if the app can't respond
immediately).  However, if you'd like for Eu to continue to respond to
events, you can use doEvents(), which I believe was introduced in 55.1.
Here's an example:

-- begin code
include win32lib.ew

constant
Win = create( Window, "Test sleep()", 0, 20, 20, 200, 200, 0),
But = create( PushButton, "Set Timer", Win, 10, 10, 100, 30, 0 )

integer sleeping
sleeping = 0
procedure win_timer( integer timer )
    atom ok
    killTimer(Win, 1)
    if sleeping then
        ok = message_box( "I'm asleep, come back later!", "Sleep Test", 0)
    else
        ok = message_box( "I'm awake, what do you want?", "Sleep Test", 0)
    end if
end procedure
onTimer[Win] = routine_id("win_timer")


procedure but_click()
    atom ok, t
    --ok = message_box( "You clicked me!", "Sleep test", 0)
    setTimer( Win, 1, 500 )
    sleeping = 1
    t = time()
    while t < time()+5 do
        doEvents(Win)
    end while
    sleeping = 0
end procedure
onClick[But] = routine_id("but_click")

WinMain( Win, Normal )
-- end code

> Now what happens if sleep(5) is hit, and 1 second later 
> something happens in windows 
> that would trigger a high-priority procedure in the 
> routine_id() list?

I'm not sure what you mean by high priority.  *Any* event sent by windows
would be reacted to by Eu using doEvents.  If you logged all the events,
you'd see that windows sends lots of messages, many of which don't need to
be dealt with by your app (stuff like losing/getting focus, etc).

> Is the line after 
> sleep(5) executed, or is that routine_id() hit first? Is it 
> possible to set the priority of the 
> routine_id()s and thereby be able to tell windoze what it is 
> supposed to be doing when 
> it's the Eu app's time to exec?

The line after sleep(5) would be executed in this case.  It works like this.
Windows puts a message in the queue for your app.  Win32Lib has a loop that
continually checks for messages.  When it gets one, it processes the
message, which often results in Windows calling your callback routines
(WndProc/SubProc in win32lib) which handle events for windows and controls.
Those callback routines, in turn, call any handlers that have been assigned.
Eventually, once you've done your processing, the program execution gets
back to the message loop, and life goes on.

Messages are handled on a first come first served basis, so there really
isn't any way to prioritize event handlers.  But, if you're calling
doEvents, then your app should respond to any events before continuing.

> This could break the throttling of blocking 
> calls in winsock apps if we 
> could set the winsock calls low priority and toss in some 
> sleep(0)s and set the rest of 
> the application to a higher priority! Can this be done in 
> win32lib, to make this trick  
> transparent to those apps which use it? Is there a priority 
> list of win callbacks, so if we 
> can't change the priorities, can we set up our code to 
> somehow pick the call that has 
> the priority we want for that code?

I don't think I understand the problem (because I'm not real familiar with
winsock).  Could you give some more detail on what's going on in the
program?  There could be another way around it.

Assuming Watcom calls win32 sleep:

The Sleep function suspends the execution of the current thread for a
specified interval. 
VOID Sleep(
    DWORD  cMilliseconds 	// sleep time in milliseconds 
   );	
Parameters

cMilliseconds
Specifies the time, in milliseconds, for which to suspend execution. A value
of zero causes the thread to relinquish the remainder of its time slice to
any other thread of equal priority that is ready to run. If there are no
other threads of equal priority ready to run, the function returns
immediately, and the thread continues execution. A value of INFINITE causes
an infinite delay. 

Return Value
This function does not return a value. 

Remarks
A thread can relinquish the remainder of its time slice by calling this
function with a sleep time of zero milliseconds. 


Matt Lewis