asynchat sends data on async_chat.push and .push_with_producer

[Jean-Paul Calderone]

On Tue, 13 May 2008 14:05:43 -0700 (PDT), Giampaolo Rodola' <gnewsg at gmail.com> wrote:
>On 13 Mag, 22:16, Jean-Paul Calderone <exar... at divmod.com> wrote:
>> On Tue, 13 May 2008 11:50:30 -0700 (PDT), Giampaolo Rodola' <gne... at gmail.com> wrote:
>> >On 13 Mag, 17:59, Josiah Carlson <josiah.carl... at gmail.com> 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