… | |
… | |
1961 | cannot be guaranteed to infinite precision. Less obviously, it cannot be |
1961 | cannot be guaranteed to infinite precision. Less obviously, it cannot be |
1962 | guaranteed to any precision by libev - imagine somebody suspending the |
1962 | guaranteed to any precision by libev - imagine somebody suspending the |
1963 | process a STOP signal for a few hours for example. |
1963 | process a STOP signal for a few hours for example. |
1964 | |
1964 | |
1965 | So, libev tries to invoke your callback as soon as possible I<after> the |
1965 | So, libev tries to invoke your callback as soon as possible I<after> the |
1966 | delay has occured, but cannot guarantee this. |
1966 | delay has occurred, but cannot guarantee this. |
1967 | |
1967 | |
1968 | A less obvious failure mode is calling your callback too early: many event |
1968 | A less obvious failure mode is calling your callback too early: many event |
1969 | loops compare timestamps with a "elapsed delay >= requested delay", but |
1969 | loops compare timestamps with a "elapsed delay >= requested delay", but |
1970 | this can cause your callback to be invoked much earlier than you would |
1970 | this can cause your callback to be invoked much earlier than you would |
1971 | expect. |
1971 | expect. |
… | |
… | |
1991 | delay has actually elapsed, or in other words, it always errs on the "too |
1991 | delay has actually elapsed, or in other words, it always errs on the "too |
1992 | late" side of things. |
1992 | late" side of things. |
1993 | |
1993 | |
1994 | =head3 The special problem of time updates |
1994 | =head3 The special problem of time updates |
1995 | |
1995 | |
1996 | Establishing the current time is a costly operation (it usually takes at |
1996 | Establishing the current time is a costly operation (it usually takes |
1997 | least two system calls): EV therefore updates its idea of the current |
1997 | at least one system call): EV therefore updates its idea of the current |
1998 | time only before and after C<ev_run> collects new events, which causes a |
1998 | time only before and after C<ev_run> collects new events, which causes a |
1999 | growing difference between C<ev_now ()> and C<ev_time ()> when handling |
1999 | growing difference between C<ev_now ()> and C<ev_time ()> when handling |
2000 | lots of events in one iteration. |
2000 | lots of events in one iteration. |
2001 | |
2001 | |
2002 | The relative timeouts are calculated relative to the C<ev_now ()> |
2002 | The relative timeouts are calculated relative to the C<ev_now ()> |
… | |
… | |
2009 | |
2009 | |
2010 | If the event loop is suspended for a long time, you can also force an |
2010 | If the event loop is suspended for a long time, you can also force an |
2011 | update of the time returned by C<ev_now ()> by calling C<ev_now_update |
2011 | update of the time returned by C<ev_now ()> by calling C<ev_now_update |
2012 | ()>. |
2012 | ()>. |
2013 | |
2013 | |
2014 | =head3 The special problem of unsychronised clocks |
2014 | =head3 The special problem of unsynchronised clocks |
2015 | |
2015 | |
2016 | Modern systems have a variety of clocks - libev itself uses the normal |
2016 | Modern systems have a variety of clocks - libev itself uses the normal |
2017 | "wall clock" clock and, if available, the monotonic clock (to avoid time |
2017 | "wall clock" clock and, if available, the monotonic clock (to avoid time |
2018 | jumps). |
2018 | jumps). |
2019 | |
2019 | |
… | |
… | |
2023 | a call to C<gettimeofday> might return a second count that is one higher |
2023 | a call to C<gettimeofday> might return a second count that is one higher |
2024 | than a directly following call to C<time>. |
2024 | than a directly following call to C<time>. |
2025 | |
2025 | |
2026 | The moral of this is to only compare libev-related timestamps with |
2026 | The moral of this is to only compare libev-related timestamps with |
2027 | C<ev_time ()> and C<ev_now ()>, at least if you want better precision than |
2027 | C<ev_time ()> and C<ev_now ()>, at least if you want better precision than |
2028 | a seocnd or so. |
2028 | a second or so. |
2029 | |
2029 | |
2030 | One more problem arises due to this lack of synchronisation: if libev uses |
2030 | One more problem arises due to this lack of synchronisation: if libev uses |
2031 | the system monotonic clock and you compare timestamps from C<ev_time> |
2031 | the system monotonic clock and you compare timestamps from C<ev_time> |
2032 | or C<ev_now> from when you started your timer and when your callback is |
2032 | or C<ev_now> from when you started your timer and when your callback is |
2033 | invoked, you will find that sometimes the callback is a bit "early". |
2033 | invoked, you will find that sometimes the callback is a bit "early". |
… | |
… | |
5132 | good enough for at least into the year 4000 with millisecond accuracy |
5132 | good enough for at least into the year 4000 with millisecond accuracy |
5133 | (the design goal for libev). This requirement is overfulfilled by |
5133 | (the design goal for libev). This requirement is overfulfilled by |
5134 | implementations using IEEE 754, which is basically all existing ones. |
5134 | implementations using IEEE 754, which is basically all existing ones. |
5135 | |
5135 | |
5136 | With IEEE 754 doubles, you get microsecond accuracy until at least the |
5136 | With IEEE 754 doubles, you get microsecond accuracy until at least the |
5137 | year 2255 (and millisecond accuray till the year 287396 - by then, libev |
5137 | year 2255 (and millisecond accuracy till the year 287396 - by then, libev |
5138 | is either obsolete or somebody patched it to use C<long double> or |
5138 | is either obsolete or somebody patched it to use C<long double> or |
5139 | something like that, just kidding). |
5139 | something like that, just kidding). |
5140 | |
5140 | |
5141 | =back |
5141 | =back |
5142 | |
5142 | |