asynchat sends data on async_chat.push and .push_with_producer

Jean-Paul Calderone exarkun at divmod.com
Tue May 13 20:56:03 EDT 2008


On Tue, 13 May 2008 16:44:11 -0700 (PDT), Giampaolo Rodola' <gnewsg at gmail.com> wrote:
>
> [snip]
>>
>> 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. ;)
>
>Yes but how do you know when it's the time to fire up a call without
>using a thread?
>You are forced to call time.time() periodically and check if that time
>had come every time.
>Take a look at twisted/internet/base/ReactorBase.runUntilCurrent.
>That's where that should happen.
>

Why?  Isn't this why subtraction exists?  If there is a call scheduled to
happen at T1 and the current time is T2, then I know that after (T1 - T2)
elapses, it will be time to run the call.  Why do I have to do any checks
at all?  I just tell select() to wait that long.  Presumably this is just
what someone will do if they want to use asyncore with timed calls.  Call
asyncore.loop() in a loop, always passing (T1 - T2) as the timeout value.

So, actually, I'm not sure what the disagreement is about. ;)  The
default value for the timeout parameter to the loop function seems
somewhat irrelevant.  If someone wants timed events in their loop,
asyncore isn't standing in their way.  On the other hand, I didn't
this thread (or maybe just this part of the thread) start out with
a question about asyncore throughput?  I have no idea what that
might have to do with this.

Jean-Paul



More information about the Python-list mailing list