diff options
Diffstat (limited to 'ev.pod')
| -rw-r--r-- | ev.pod | 18 |
1 files changed, 9 insertions, 9 deletions
@@ -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). |