Browse Source

applied µikachus corrections

master
Marc Alexander Lehmann 14 years ago
parent
commit
8986c89ea2
  1. 18
      ev.pod

18
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).

Loading…
Cancel
Save