On 11:47 am, g.rod...@gmail.com wrote:
2010/5/7 Antoine Pitrou <solip...@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
--
http://mail.python.org/mailman/listinfo/python-list
