| … | |
… | |
| 417 | i.e. keep at least one watcher active per fd at all times. Stopping and |
417 | i.e. keep at least one watcher active per fd at all times. Stopping and |
| 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 | |
|
|
423 | All this means that, in practise, C<EVBACKEND_SELECT> is as fast or faster |
|
|
424 | then epoll for maybe up to a hundred file descriptors. So sad. |
| 422 | |
425 | |
| 423 | While nominally embeddable in other event loops, this feature is broken in |
426 | While nominally embeddable in other event loops, this feature is broken in |
| 424 | all kernel versions tested so far. |
427 | all kernel versions tested so far. |
| 425 | |
428 | |
| 426 | This backend maps C<EV_READ> and C<EV_WRITE> in the same way as |
429 | This backend maps C<EV_READ> and C<EV_WRITE> in the same way as |
| … | |
… | |
| 1998 | There is no support for kqueue, as apparently it cannot be used to |
2001 | There is no support for kqueue, as apparently it cannot be used to |
| 1999 | implement this functionality, due to the requirement of having a file |
2002 | implement this functionality, due to the requirement of having a file |
| 2000 | descriptor open on the object at all times, and detecting renames, unlinks |
2003 | descriptor open on the object at all times, and detecting renames, unlinks |
| 2001 | etc. is difficult. |
2004 | etc. is difficult. |
| 2002 | |
2005 | |
|
|
2006 | =head3 C<stat ()> is a synchronous operation |
|
|
2007 | |
|
|
2008 | Libev doesn't normally do any kind of I/O itself, and so is not blocking |
|
|
2009 | the process. The exception are C<ev_stat> watchers - those call C<stat |
|
|
2010 | ()>, which is a synchronous operation. |
|
|
2011 | |
|
|
2012 | For local paths, this usually doesn't matter: unless the system is very |
|
|
2013 | busy or the intervals between stat's are large, a stat call will be fast, |
|
|
2014 | as the path data is suually in memory already (except when starting the |
|
|
2015 | watcher). |
|
|
2016 | |
|
|
2017 | For networked file systems, calling C<stat ()> can block an indefinite |
|
|
2018 | time due to network issues, and even under good conditions, a stat call |
|
|
2019 | often takes multiple milliseconds. |
|
|
2020 | |
|
|
2021 | Therefore, it is best to avoid using C<ev_stat> watchers on networked |
|
|
2022 | paths, although this is fully supported by libev. |
|
|
2023 | |
| 2003 | =head3 The special problem of stat time resolution |
2024 | =head3 The special problem of stat time resolution |
| 2004 | |
2025 | |
| 2005 | The C<stat ()> system call only supports full-second resolution portably, |
2026 | The C<stat ()> system call only supports full-second resolution portably, |
| 2006 | and even on systems where the resolution is higher, most file systems |
2027 | and even on systems where the resolution is higher, most file systems |
| 2007 | still only support whole seconds. |
2028 | still only support whole seconds. |
