summaryrefslogtreecommitdiff
path: root/ev.pod
diff options
context:
space:
mode:
Diffstat (limited to 'ev.pod')
-rw-r--r--ev.pod18
1 files changed, 9 insertions, 9 deletions
diff --git a/ev.pod b/ev.pod
index 5cc3be2..ee00c06 100644
--- a/ev.pod
+++ b/ev.pod
@@ -338,7 +338,7 @@ parallelity (most of the file descriptors should be busy). If you are
writing a server, you should C<accept ()> in a loop to accept as many
connections as possible during one iteration. You might also want to have
a look at C<ev_set_io_collect_interval ()> to increase the amount of
-readyness notifications you get per iteration.
+readiness notifications you get per iteration.
=item C<EVBACKEND_POLL> (value 2, poll backend, available everywhere except on windows)
@@ -427,7 +427,7 @@ file descriptor per loop iteration. For small and medium numbers of file
descriptors a "slow" C<EVBACKEND_SELECT> or C<EVBACKEND_POLL> backend
might perform better.
-On the positive side, ignoring the spurious readyness notifications, this
+On the positive side, ignoring the spurious readiness notifications, this
backend actually performed to specification in all tests and is fully
embeddable, which is a rare feat among the OS-specific backends.
@@ -1034,7 +1034,7 @@ If you must do this, then force the use of a known-to-be-good backend
C<EVBACKEND_POLL>).
Another thing you have to watch out for is that it is quite easy to
-receive "spurious" readyness notifications, that is your callback might
+receive "spurious" readiness notifications, that is your callback might
be called with C<EV_READ> but a subsequent C<read>(2) will actually block
because there is no data. Not only are some backends known to create a
lot of those (for example solaris ports), it is very easy to get into
@@ -1659,7 +1659,7 @@ within the same second, C<ev_stat> will be unable to detect it as the stat
data does not change.
The solution to this is to delay acting on a change for slightly more
-than second (or till slightly after the next full second boundary), using
+than a second (or till slightly after the next full second boundary), using
a roughly one-second-delay C<ev_timer> (e.g. C<ev_timer_set (w, 0., 1.02);
ev_timer_again (loop, w)>).
@@ -3005,8 +3005,8 @@ two).
Heaps are not very cache-efficient. To improve the cache-efficiency of the
timer and periodics heap, libev uses a 4-heap when this symbol is defined
-to C<1>. The 4-heap uses more complicated (longer) code but has a
-noticable after performance with many (thousands) of watchers.
+to C<1>. The 4-heap uses more complicated (longer) code but has
+noticably faster performance with many (thousands) of watchers.
The default is C<1> unless C<EV_MINIMAL> is set in which case it is C<0>
(disabled).
@@ -3017,8 +3017,8 @@ Heaps are not very cache-efficient. To improve the cache-efficiency of the
timer and periodics heap, libev can cache the timestamp (I<at>) within
the heap structure (selected by defining C<EV_HEAP_CACHE_AT> to C<1>),
which uses 8-12 bytes more per watcher and a few hundred bytes more code,
-but avoids random read accesses on heap changes. This noticably improves
-performance noticably with with many (hundreds) of watchers.
+but avoids random read accesses on heap changes. This improves performance
+noticably with with many (hundreds) of watchers.
The default is C<1> unless C<EV_MINIMAL> is set in which case it is C<0>
(disabled).
@@ -3253,7 +3253,7 @@ Due to the many, low, and arbitrary limits on the win32 platform and
the abysmal performance of winsockets, using a large number of sockets
is not recommended (and not reasonable). If your program needs to use
more than a hundred or so sockets, then likely it needs to use a totally
-different implementation for windows, as libev offers the POSIX readyness
+different implementation for windows, as libev offers the POSIX readiness
notification model, which cannot be implemented efficiently on windows
(microsoft monopoly games).