summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorsf-exg <sf-exg>2011-08-15 10:18:07 +0000
committersf-exg <sf-exg>2011-08-15 10:18:07 +0000
commit16ca6f60d0af7ccf7c928c8b165a848d7365efa4 (patch)
tree677d78b108e1754f7ed8e3faa3a8652527d2c3ec
parentcc698e0eda8e45e5d4e04453c48e03118fcff201 (diff)
Fix typos.
-rw-r--r--ev.pod6
1 files changed, 3 insertions, 3 deletions
diff --git a/ev.pod b/ev.pod
index f3cefd2..30e8ca1 100644
--- a/ev.pod
+++ b/ev.pod
@@ -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).