… | |
… | |
418 | starting a watcher (without re-setting it) also usually doesn't cause |
418 | starting a watcher (without re-setting it) also usually doesn't cause |
419 | extra overhead. A fork can both result in spurious notifications as well |
419 | extra overhead. A fork can both result in spurious notifications as well |
420 | as in libev having to destroy and recreate the epoll object, which can |
420 | as in libev having to destroy and recreate the epoll object, which can |
421 | take considerable time and thus should be avoided. |
421 | take considerable time and thus should be avoided. |
422 | |
422 | |
423 | All this means that, in practise, C<EVBACKEND_SELECT> is as fast or faster |
423 | All this means that, in practise, C<EVBACKEND_SELECT> can be as fast or |
424 | then epoll for maybe up to a hundred file descriptors. So sad. |
424 | faster then epoll for maybe up to a hundred file descriptors, depending on |
|
|
425 | the usage. So sad. |
425 | |
426 | |
426 | While nominally embeddable in other event loops, this feature is broken in |
427 | While nominally embeddable in other event loops, this feature is broken in |
427 | all kernel versions tested so far. |
428 | all kernel versions tested so far. |
428 | |
429 | |
429 | This backend maps C<EV_READ> and C<EV_WRITE> in the same way as |
430 | This backend maps C<EV_READ> and C<EV_WRITE> in the same way as |