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