| … | |
… | |
| 336 | To get good performance out of this backend you need a high amount of |
336 | To get good performance out of this backend you need a high amount of |
| 337 | parallelity (most of the file descriptors should be busy). If you are |
337 | parallelity (most of the file descriptors should be busy). If you are |
| 338 | writing a server, you should C<accept ()> in a loop to accept as many |
338 | writing a server, you should C<accept ()> in a loop to accept as many |
| 339 | connections as possible during one iteration. You might also want to have |
339 | connections as possible during one iteration. You might also want to have |
| 340 | a look at C<ev_set_io_collect_interval ()> to increase the amount of |
340 | a look at C<ev_set_io_collect_interval ()> to increase the amount of |
| 341 | readyness notifications you get per iteration. |
341 | readiness notifications you get per iteration. |
| 342 | |
342 | |
| 343 | =item C<EVBACKEND_POLL> (value 2, poll backend, available everywhere except on windows) |
343 | =item C<EVBACKEND_POLL> (value 2, poll backend, available everywhere except on windows) |
| 344 | |
344 | |
| 345 | And this is your standard poll(2) backend. It's more complicated |
345 | And this is your standard poll(2) backend. It's more complicated |
| 346 | than select, but handles sparse fds better and has no artificial |
346 | than select, but handles sparse fds better and has no artificial |
| … | |
… | |
| 425 | While this backend scales well, it requires one system call per active |
425 | While this backend scales well, it requires one system call per active |
| 426 | file descriptor per loop iteration. For small and medium numbers of file |
426 | file descriptor per loop iteration. For small and medium numbers of file |
| 427 | descriptors a "slow" C<EVBACKEND_SELECT> or C<EVBACKEND_POLL> backend |
427 | descriptors a "slow" C<EVBACKEND_SELECT> or C<EVBACKEND_POLL> backend |
| 428 | might perform better. |
428 | might perform better. |
| 429 | |
429 | |
| 430 | On the positive side, ignoring the spurious readyness notifications, this |
430 | On the positive side, ignoring the spurious readiness notifications, this |
| 431 | backend actually performed to specification in all tests and is fully |
431 | backend actually performed to specification in all tests and is fully |
| 432 | embeddable, which is a rare feat among the OS-specific backends. |
432 | embeddable, which is a rare feat among the OS-specific backends. |
| 433 | |
433 | |
| 434 | =item C<EVBACKEND_ALL> |
434 | =item C<EVBACKEND_ALL> |
| 435 | |
435 | |
| … | |
… | |
| 1032 | If you must do this, then force the use of a known-to-be-good backend |
1032 | If you must do this, then force the use of a known-to-be-good backend |
| 1033 | (at the time of this writing, this includes only C<EVBACKEND_SELECT> and |
1033 | (at the time of this writing, this includes only C<EVBACKEND_SELECT> and |
| 1034 | C<EVBACKEND_POLL>). |
1034 | C<EVBACKEND_POLL>). |
| 1035 | |
1035 | |
| 1036 | Another thing you have to watch out for is that it is quite easy to |
1036 | Another thing you have to watch out for is that it is quite easy to |
| 1037 | receive "spurious" readyness notifications, that is your callback might |
1037 | receive "spurious" readiness notifications, that is your callback might |
| 1038 | be called with C<EV_READ> but a subsequent C<read>(2) will actually block |
1038 | be called with C<EV_READ> but a subsequent C<read>(2) will actually block |
| 1039 | because there is no data. Not only are some backends known to create a |
1039 | because there is no data. Not only are some backends known to create a |
| 1040 | lot of those (for example solaris ports), it is very easy to get into |
1040 | lot of those (for example solaris ports), it is very easy to get into |
| 1041 | this situation even with a relatively standard program structure. Thus |
1041 | this situation even with a relatively standard program structure. Thus |
| 1042 | it is best to always use non-blocking I/O: An extra C<read>(2) returning |
1042 | it is best to always use non-blocking I/O: An extra C<read>(2) returning |
| … | |
… | |
| 1657 | calls your callback, which does something. When there is another update |
1657 | calls your callback, which does something. When there is another update |
| 1658 | within the same second, C<ev_stat> will be unable to detect it as the stat |
1658 | within the same second, C<ev_stat> will be unable to detect it as the stat |
| 1659 | data does not change. |
1659 | data does not change. |
| 1660 | |
1660 | |
| 1661 | The solution to this is to delay acting on a change for slightly more |
1661 | The solution to this is to delay acting on a change for slightly more |
| 1662 | than second (or till slightly after the next full second boundary), using |
1662 | than a second (or till slightly after the next full second boundary), using |
| 1663 | a roughly one-second-delay C<ev_timer> (e.g. C<ev_timer_set (w, 0., 1.02); |
1663 | a roughly one-second-delay C<ev_timer> (e.g. C<ev_timer_set (w, 0., 1.02); |
| 1664 | ev_timer_again (loop, w)>). |
1664 | ev_timer_again (loop, w)>). |
| 1665 | |
1665 | |
| 1666 | The C<.02> offset is added to work around small timing inconsistencies |
1666 | The C<.02> offset is added to work around small timing inconsistencies |
| 1667 | of some operating systems (where the second counter of the current time |
1667 | of some operating systems (where the second counter of the current time |
| … | |
… | |
| 3003 | |
3003 | |
| 3004 | =item EV_USE_4HEAP |
3004 | =item EV_USE_4HEAP |
| 3005 | |
3005 | |
| 3006 | Heaps are not very cache-efficient. To improve the cache-efficiency of the |
3006 | Heaps are not very cache-efficient. To improve the cache-efficiency of the |
| 3007 | timer and periodics heap, libev uses a 4-heap when this symbol is defined |
3007 | timer and periodics heap, libev uses a 4-heap when this symbol is defined |
| 3008 | to C<1>. The 4-heap uses more complicated (longer) code but has a |
3008 | to C<1>. The 4-heap uses more complicated (longer) code but has |
| 3009 | noticable after performance with many (thousands) of watchers. |
3009 | noticably faster performance with many (thousands) of watchers. |
| 3010 | |
3010 | |
| 3011 | The default is C<1> unless C<EV_MINIMAL> is set in which case it is C<0> |
3011 | The default is C<1> unless C<EV_MINIMAL> is set in which case it is C<0> |
| 3012 | (disabled). |
3012 | (disabled). |
| 3013 | |
3013 | |
| 3014 | =item EV_HEAP_CACHE_AT |
3014 | =item EV_HEAP_CACHE_AT |
| 3015 | |
3015 | |
| 3016 | Heaps are not very cache-efficient. To improve the cache-efficiency of the |
3016 | Heaps are not very cache-efficient. To improve the cache-efficiency of the |
| 3017 | timer and periodics heap, libev can cache the timestamp (I<at>) within |
3017 | timer and periodics heap, libev can cache the timestamp (I<at>) within |
| 3018 | the heap structure (selected by defining C<EV_HEAP_CACHE_AT> to C<1>), |
3018 | the heap structure (selected by defining C<EV_HEAP_CACHE_AT> to C<1>), |
| 3019 | which uses 8-12 bytes more per watcher and a few hundred bytes more code, |
3019 | which uses 8-12 bytes more per watcher and a few hundred bytes more code, |
| 3020 | but avoids random read accesses on heap changes. This noticably improves |
3020 | but avoids random read accesses on heap changes. This improves performance |
| 3021 | performance noticably with with many (hundreds) of watchers. |
3021 | noticably with with many (hundreds) of watchers. |
| 3022 | |
3022 | |
| 3023 | The default is C<1> unless C<EV_MINIMAL> is set in which case it is C<0> |
3023 | The default is C<1> unless C<EV_MINIMAL> is set in which case it is C<0> |
| 3024 | (disabled). |
3024 | (disabled). |
| 3025 | |
3025 | |
| 3026 | =item EV_COMMON |
3026 | =item EV_COMMON |
| … | |
… | |
| 3251 | |
3251 | |
| 3252 | Due to the many, low, and arbitrary limits on the win32 platform and |
3252 | Due to the many, low, and arbitrary limits on the win32 platform and |
| 3253 | the abysmal performance of winsockets, using a large number of sockets |
3253 | the abysmal performance of winsockets, using a large number of sockets |
| 3254 | is not recommended (and not reasonable). If your program needs to use |
3254 | is not recommended (and not reasonable). If your program needs to use |
| 3255 | more than a hundred or so sockets, then likely it needs to use a totally |
3255 | more than a hundred or so sockets, then likely it needs to use a totally |
| 3256 | different implementation for windows, as libev offers the POSIX readyness |
3256 | different implementation for windows, as libev offers the POSIX readiness |
| 3257 | notification model, which cannot be implemented efficiently on windows |
3257 | notification model, which cannot be implemented efficiently on windows |
| 3258 | (microsoft monopoly games). |
3258 | (microsoft monopoly games). |
| 3259 | |
3259 | |
| 3260 | =over 4 |
3260 | =over 4 |
| 3261 | |
3261 | |
