| … | |
… | |
| 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. |
| … | |
… | |
| 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 | |
