diff options
author | sf-exg <sf-exg> | 2011-08-15 10:18:07 +0000 |
---|---|---|
committer | sf-exg <sf-exg> | 2011-08-15 10:18:07 +0000 |
commit | 16ca6f60d0af7ccf7c928c8b165a848d7365efa4 (patch) | |
tree | 677d78b108e1754f7ed8e3faa3a8652527d2c3ec | |
parent | cc698e0eda8e45e5d4e04453c48e03118fcff201 (diff) |
Fix typos.
-rw-r--r-- | ev.pod | 6 |
1 files changed, 3 insertions, 3 deletions
@@ -1963,7 +1963,7 @@ guaranteed to any precision by libev - imagine somebody suspending the process a STOP signal for a few hours for example. So, libev tries to invoke your callback as soon as possible I<after> the -delay has occured, but cannot guarantee this. +delay has occurred, but cannot guarantee this. A less obvious failure mode is calling your callback too early: many event loops compare timestamps with a "elapsed delay >= requested delay", but @@ -2025,7 +2025,7 @@ than a directly following call to C<time>. The moral of this is to only compare libev-related timestamps with C<ev_time ()> and C<ev_now ()>, at least if you want better precision than -a seocnd or so. +a second or so. One more problem arises due to this lack of synchronisation: if libev uses the system monotonic clock and you compare timestamps from C<ev_time> @@ -5134,7 +5134,7 @@ good enough for at least into the year 4000 with millisecond accuracy implementations using IEEE 754, which is basically all existing ones. With IEEE 754 doubles, you get microsecond accuracy until at least the -year 2255 (and millisecond accuray till the year 287396 - by then, libev +year 2255 (and millisecond accuracy till the year 287396 - by then, libev is either obsolete or somebody patched it to use C<long double> or something like that, just kidding). |