Windows - select.select, timeout and KeyboardInterrupt

Giampaolo Rodolà g.rodola at gmail.com
Sat May 8 07:47:53 EDT 2010


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.


--- Giampaolo
http://code.google.com/p/pyftpdlib
http://code.google.com/p/psutil



More information about the Python-list mailing list