On Sat, Oct 15, 2011 at 08:53:56AM -0500, Brandon Black blbl...@gmail.com
wrote:
the timer has got an event but the IO hasn't yet.
Priorities should still fix things, within the limitation that they
can't make the timer fire on time if the loop iteration is taking
consider the following
On Sat, Oct 15, 2011 at 01:40:25PM +0700, Denis Bilenko
denis.bile...@gmail.com wrote:
I know about ev_now_update(). In fact, I've suggested to Shaun on
gevent mailing list
to call ev_now_update() periodically via setitimer. This only helps
with timeouts bigger than
the setitimer period
On Fri, Oct 14, 2011 at 12:48 AM, Shaun Lindsay srlind...@gmail.com wrote:
The problem isn't the volume of timer events. Condensing all the timeouts
to one actual event won't help since, as shown in the example, a single
timeout is vulnerable to early expiration. Basing all your timeouts off
On Tue, Oct 11, 2011 at 05:15:54PM -0700, Shaun Lindsay srlind...@gmail.com
wrote:
Hello,
Hi!
As mentioned in the above link, you can force an update of the cached time
via ev_update_now(), but this doesn't practically address the issue.
Well, it should address the issue, thats what it is
I think my description of the issue was lacking. This is not specific to
gevent. To illustrate the problem, I've included a C test program that
reproduces the timeout problems. I'll be referring back to that test code
as I reply inline to your comments. To simulate a real workload, the test
libev's way of doing things (using loop start time) is just more
efficient for most normal cases, because normally you don't have large
delays/blocks in your callbacks in an event-driven program. In the
big picture, it sounds like the primary issue in your original code is
that you're
