On Thu, Aug 21, 2014 at 01:33:49PM +0000, "Aviv Heller (avheller)"
<avhel...@cisco.com> wrote:
> I have encountered a problem, on version 4.11 of the library, where a timer
> started expired prior to its intended expiry time.
The documentation is far ahead of you here: see "The special problem of
time updates" in the documentation for more information.
In short, this seems to be a usage bug on your side - libev cannot guess
what you "intended", it can only go by what you tell it to do - you can
base your timers on whatever reference time you want, but if it isn't
ev_now() (the default) you need to make it explicit.
> The fix I propose is to have ev_timer_start() call time_update() before
> calculating the expiry timestamp (patch attached).
That would be a rather bad idea - this would make it hard to get
deterministic timing (timing based on external events), and would still
not fix your problem. It would simply reduce the time window where you can
fall for that race condition.
Or in other words, if you can't cope with that race condition and consider
it a bug, this is a bug in your program, and it _cannot_ be fixed in
libev: Your suggestion would reduce the likelihood of the race occuring,
but the race condition still exists, as it exists outside of libev (and
outside of your program).
You can reduce the window of time for that race condition to occur (see
the docs referenced above), but there is no way to avoid it happening.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
