| … | |
… | |
| 384 | =item C<EVBACKEND_EPOLL> (value 4, Linux) |
384 | =item C<EVBACKEND_EPOLL> (value 4, Linux) |
| 385 | |
385 | |
| 386 | For few fds, this backend is a bit little slower than poll and select, |
386 | For few fds, this backend is a bit little slower than poll and select, |
| 387 | but it scales phenomenally better. While poll and select usually scale |
387 | but it scales phenomenally better. While poll and select usually scale |
| 388 | like O(total_fds) where n is the total number of fds (or the highest fd), |
388 | like O(total_fds) where n is the total number of fds (or the highest fd), |
| 389 | epoll scales either O(1) or O(active_fds). The epoll design has a number |
389 | epoll scales either O(1) or O(active_fds). |
| 390 | of shortcomings, such as silently dropping events in some hard-to-detect |
390 | |
| 391 | cases and requiring a system call per fd change, no fork support and bad |
391 | The epoll syscalls are the most misdesigned of the more advanced |
| 392 | support for dup. |
392 | event mechanisms: probelsm include silently dropping events in some |
|
|
393 | hard-to-detect cases, requiring a system call per fd change, no fork |
|
|
394 | support, problems with dup and so on. |
|
|
395 | |
|
|
396 | Epoll is also notoriously buggy - embedding epoll fds should work, but |
|
|
397 | of course doesn't, and epoll just loves to report events for totally |
|
|
398 | I<different> file descriptors (even already closed ones, so one cannot |
|
|
399 | even remove them from the set) than registered in the set (especially |
|
|
400 | on SMP systems). Libev tries to counter these spurious notifications by |
|
|
401 | employing an additional generation counter and comparing that against the |
|
|
402 | events to filter out spurious ones. |
| 393 | |
403 | |
| 394 | While stopping, setting and starting an I/O watcher in the same iteration |
404 | While stopping, setting and starting an I/O watcher in the same iteration |
| 395 | will result in some caching, there is still a system call per such incident |
405 | will result in some caching, there is still a system call per such incident |
| 396 | (because the fd could point to a different file description now), so its |
406 | (because the fd could point to a different file description now), so its |
| 397 | best to avoid that. Also, C<dup ()>'ed file descriptors might not work |
407 | best to avoid that. Also, C<dup ()>'ed file descriptors might not work |
| 398 | very well if you register events for both fds. |
408 | very well if you register events for both fds. |
| 399 | |
|
|
| 400 | Please note that epoll sometimes generates spurious notifications, so you |
|
|
| 401 | need to use non-blocking I/O or other means to avoid blocking when no data |
|
|
| 402 | (or space) is available. |
|
|
| 403 | |
409 | |
| 404 | Best performance from this backend is achieved by not unregistering all |
410 | Best performance from this backend is achieved by not unregistering all |
| 405 | watchers for a file descriptor until it has been closed, if possible, |
411 | watchers for a file descriptor until it has been closed, if possible, |
| 406 | i.e. keep at least one watcher active per fd at all times. Stopping and |
412 | i.e. keep at least one watcher active per fd at all times. Stopping and |
| 407 | starting a watcher (without re-setting it) also usually doesn't cause |
413 | starting a watcher (without re-setting it) also usually doesn't cause |
| … | |
… | |
| 531 | responsibility to either stop all watchers cleanly yourself I<before> |
537 | responsibility to either stop all watchers cleanly yourself I<before> |
| 532 | calling this function, or cope with the fact afterwards (which is usually |
538 | calling this function, or cope with the fact afterwards (which is usually |
| 533 | the easiest thing, you can just ignore the watchers and/or C<free ()> them |
539 | the easiest thing, you can just ignore the watchers and/or C<free ()> them |
| 534 | for example). |
540 | for example). |
| 535 | |
541 | |
| 536 | Note that certain global state, such as signal state, will not be freed by |
542 | Note that certain global state, such as signal state (and installed signal |
| 537 | this function, and related watchers (such as signal and child watchers) |
543 | handlers), will not be freed by this function, and related watchers (such |
| 538 | would need to be stopped manually. |
544 | as signal and child watchers) would need to be stopped manually. |
| 539 | |
545 | |
| 540 | In general it is not advisable to call this function except in the |
546 | In general it is not advisable to call this function except in the |
| 541 | rare occasion where you really need to free e.g. the signal handling |
547 | rare occasion where you really need to free e.g. the signal handling |
| 542 | pipe fds. If you need dynamically allocated loops it is better to use |
548 | pipe fds. If you need dynamically allocated loops it is better to use |
| 543 | C<ev_loop_new> and C<ev_loop_destroy>). |
549 | C<ev_loop_new> and C<ev_loop_destroy>). |
