alternate approach to timer inaccuracy due to cached times

[Marc Lehmann]

On Fri, Oct 14, 2011 at 06:34:47PM +0700, Denis Bilenko <denis.bilenko at gmail.com> wrote:
> On Fri, Oct 14, 2011 at 3:59 PM, Marc Lehmann <schmorp at schmorp.de> wrote:
> > I do think I understand you, and I do maintain this is a design shortcoming
> > in gevent that is not shared by other code based on libev (or other event
> > libraries).
> 
> I fail to see how it's a design shortcoming in gevent.

Thats a pity - since there have been elaborate explanations given, what
exactly do you not understand?

> work. If you still think there's more than that, I'd like to hear it.

Well, yes.

> Here's how the problem manifests itself in gevent:
> time.sleep(7)  # system call sleep
> gevent.sleep(10)  # this uses ev_timer to wake up the coroutine. it
> sleeps for 3 seconds instead.

Well, you can always call ev_now_update after such a long blocking
operation. Or take timestamps more often, to get better accuracy. Or use
proper timeouts.

Your example basically says: "if I sleep 7 seconds, then a 7 second
timeout might trigger unexpectedly in a naive implementation of
timeouts". Well, if you sleep 7 seconds, then a 7 second timeout is
meaningless, because it is below the accuracy you can actually achieve.

Timeouts do not get their values by some elaborate mathematical formula -
timeouts are deeply rooted in the real world, and slow devices usually need
higher timeouts than fast ones. You have to take reality into account.

> Your Perl's Coro library probably has sleep() function that uses
> ev_timer as well? If that's the case,
> it's susceptible to this issue the same way.

No, becauase Coro doesn't do I/O the same way, it uses design (2) from my
previous mails for actual I/O events.

> I think it would be better for libev is to use future timestamp
> instead of past timestamp.

I think it would be worse, and I have explained why: the current behaviour
lets you specify exactly what you want, without requiring complicated
constructs such as second-guessing libev.

> I think it would be better because timeouts firing later than
> specified are usually not fatal for the application while timeouts
> firing earlier usually are.

Well, libev never fires timers earlier than specified, so this is not your
issue.

The issue arises because two different clocks are being compared, which
is always confusing in cases where they don't match.

And the issue is a non-issue, because there are simple-to-implement
designs which do not suffer from this problem.

> Are there any good reasons to prefer the past timestamp instead of the
> future one?

Apparently my reasons weren't good for you - you should explain why.

The main reason is that right now, you can easily get whatever behaviour
you want (and the default behaviour is what you usually want). With the
patch that becomes much harder.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\