Event loop and sleep()

[Alo Sarv]

sleep does not change the priority of a process in Window, nor in any other
system I know of.

DrX

I think I failed to make my intentions clear, so let me clarify:

The application is singlethreaded, all events are received from
sockets. The purpose of sleep() was to wake up at some interval, check
if there is anything to process from sockets, and then go back to
sleep. I don't see a way to make the system blocking without coupling
event engine directly with sockets. Additionally, there might pending
jobs that take long time (checksumming files for example), that should
be done in small amounts (64k blocks for example) during event loops.
Or there could be jobs that need to be done at specific intervals (for
example, autosaving config file every 20 minutes). Thus blocking
the loop if there are no socket events isn't an option, since that
would also block those jobs. Removing the sleep() from the loop causes
the loop to run as fast as possible, thus using 100% CPU (on any
system/compiler).

One option that was pointed out in this thread was to loop around
until there are events to process, and then go to sleep for a minimum
delay. Now, if an event handler function posts a new event, that event
also needs to be processed. And if a handler for the new event also
posts a event, that one also needs to be processed, thus can cause
endless loop if the user of the event system isn't careful... Ok, this
could be countered by limiting the number of runs through event loop
w/o sleeping to some amount, after which a sleep will be forced. Can't
say I'm exactly thrilled with this solution.

Alo.

 

[Xenos]

"Xenos" <[email protected]> wrote in message

I think I failed to make my intentions clear, so let me clarify:

The application is singlethreaded, all events are received from
sockets. The purpose of sleep() was to wake up at some interval, check
if there is anything to process from sockets, and then go back to
sleep. I don't see a way to make the system blocking without coupling
event engine directly with sockets. Additionally, there might pending
jobs that take long time (checksumming files for example), that should
be done in small amounts (64k blocks for example) during event loops.
Or there could be jobs that need to be done at specific intervals (for
example, autosaving config file every 20 minutes). Thus blocking
the loop if there are no socket events isn't an option, since that
would also block those jobs. Removing the sleep() from the loop causes
the loop to run as fast as possible, thus using 100% CPU (on any
system/compiler).

One option that was pointed out in this thread was to loop around
until there are events to process, and then go to sleep for a minimum
delay. Now, if an event handler function posts a new event, that event
also needs to be processed. And if a handler for the new event also
posts a event, that one also needs to be processed, thus can cause
endless loop if the user of the event system isn't careful... Ok, this
could be countered by limiting the number of runs through event loop
w/o sleeping to some amount, after which a sleep will be forced. Can't
say I'm exactly thrilled with this solution.

Alo.

Although this thread is a bit off-topic, there are many more ways to make a
thread block then just sockets. As someone suggested, the message queue
itself can cause the thread to block when its empty. If that's not already
a property of the queue, the funtionally can be achieved by wrapping the
read of the queue with the taking of a semaphore, and the write with the
giving the semaphore (text book reader-writer mechanism). Artifically
blocking via delays is, in my humble opinion usually bad. The event to be
handled is decoupled and asynchronous to the thead of execution that is
process it. It is always best if the two can be tied together so that it's
the event the awakens the task. The task will not waste time sleeping when
there are events to process and it will not waste the processor polling for
events when they are not there.