Windows - select.select, timeout and KeyboardInterrupt

[exarkun at twistedmatrix.com]

On 11:47 am, g.rodola at gmail.com wrote:
>2010/5/7 Antoine Pitrou <solipsis at pitrou.net>:
>>Le Fri, 07 May 2010 21:55:15 +0200, Giampaolo Rodolà a écrit :
>>>Of course, but 30 seconds look a little bit too much to me, also 
>>>because
>>>(I might be wrong here) I noticed that a smaller timeout seems to 
>>>result
>>>in better performances.
>>
>>That's probably bogus.
>
>Probably, I'll try to write a benchmark script and see what happens.
>>>Plus, if scheduled callbacks are ever gonna be added to asyncore we
>>>would be forced to lower the default timeout anyway in order to have 
>>>a
>>>decent reactivity.
>>
>>Why?
>
>Assuming loop() function does something like this:
>
>     ...
>     select.select(r, w, e, timeout)
>     scheduler()  # checks for scheduled calls to be fired
>     ...
>
>...imagine a case where there's a connection (aka a dispatcher
>instance) which does not receive or send any data *and* a scheduled
>call which is supposed to be fired after, say, 5 seconds.
>The entire loop would hang on select.select() which won't return for
>30 seconds because the socket is not ready for reading and/or writing
>resulting in scheduler() be called too late.

This would be an intensely lame way to implement support for scheduled 
callbacks.  Try this trivial modification instead, to make it awesome:

    ...
    select.select(r, w, e, scheduler.time_until_next_call())
    scheduler.run()
    ...

(Or maybe just use Twisted. ;)

Jean-Paul