| … | |
… | |
| 174 | =item ev_tstamp ev_time () |
174 | =item ev_tstamp ev_time () |
| 175 | |
175 | |
| 176 | Returns the current time as libev would use it. Please note that the |
176 | Returns the current time as libev would use it. Please note that the |
| 177 | C<ev_now> function is usually faster and also often returns the timestamp |
177 | C<ev_now> function is usually faster and also often returns the timestamp |
| 178 | you actually want to know. Also interesting is the combination of |
178 | you actually want to know. Also interesting is the combination of |
| 179 | C<ev_update_now> and C<ev_now>. |
179 | C<ev_now_update> and C<ev_now>. |
| 180 | |
180 | |
| 181 | =item ev_sleep (ev_tstamp interval) |
181 | =item ev_sleep (ev_tstamp interval) |
| 182 | |
182 | |
| 183 | Sleep for the given interval: The current thread will be blocked |
183 | Sleep for the given interval: The current thread will be blocked |
| 184 | until either it is interrupted or the given time interval has |
184 | until either it is interrupted or the given time interval has |
| … | |
… | |
| 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 | |
