On Tue, 13 May 2008 20:56:03 -0400, Jean-Paul Calderone <[EMAIL PROTECTED]>
wrote:
On Tue, 13 May 2008 16:44:11 -0700 (PDT), Giampaolo Rodola'
<[EMAIL PROTECTED]> 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.
Ah, of course this is wrong, since asyncore.loop... loops. :P I meant to
say asyncore.poll() here.
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
--
http://mail.python.org/mailman/listinfo/python-list
