On Tue, 13 May 2008 14:05:43 -0700 (PDT), Giampaolo Rodola' <[EMAIL PROTECTED]>
wrote:
On 13 Mag, 22:16, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
On Tue, 13 May 2008 11:50:30 -0700 (PDT), Giampaolo Rodola' <[EMAIL PROTECTED]>
wrote:
>On 13 Mag, 17:59, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>> We do not live in a pure world, Python isn't pure (practicality beats
>> purity), and by attempting to send some data each time a .push*()
>> method is called, there are measurable increases in transfer rates.
>Good point. I'd like to ask a question: if we'd have a default
>asyncore.loop timeout of (say) 0.01 ms instead of 30 could we avoid
>such problem?
>I've always found weird that asyncore has such an high default timeout
>value.
>Twisted, for example, uses a default of 0.01 ms for all its reactors.
I'm not sure this is right. What timeout are we talking about? Twisted
only wakes up when necessary.
Jean-Paul
I'm talking about the asyncore.loop timeout parameter which defaults
to 30 (seconds).
I don't think that Twisted only wakes up when necessary (surely not by
using the select reactor).
Think about the schedule calls feature (reactor.callLater).
To have that work I guess that a continuous loop must always be kept
alive, regardless of the reactor used.
To support scheduling calls, you just have to know when the next call is
going to happen. Then, you can wake up at exactly that time. This is
what Twisted does, even for select reactor. ;)
An exception to this is that on Windows, in order to support ^C, the
reactor will wake up more often, because ^C does not interrupt select()
in Python on Windows (although this could probably be fixed).
Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list
