… | |
… | |
8 | |
8 | |
9 | =head2 EXAMPLE PROGRAM |
9 | =head2 EXAMPLE PROGRAM |
10 | |
10 | |
11 | // a single header file is required |
11 | // a single header file is required |
12 | #include <ev.h> |
12 | #include <ev.h> |
|
|
13 | |
|
|
14 | #include <stdio.h> // for puts |
13 | |
15 | |
14 | // every watcher type has its own typedef'd struct |
16 | // every watcher type has its own typedef'd struct |
15 | // with the name ev_TYPE |
17 | // with the name ev_TYPE |
16 | ev_io stdin_watcher; |
18 | ev_io stdin_watcher; |
17 | ev_timer timeout_watcher; |
19 | ev_timer timeout_watcher; |
… | |
… | |
417 | i.e. keep at least one watcher active per fd at all times. Stopping and |
419 | 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 |
420 | 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 |
421 | 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 |
422 | as in libev having to destroy and recreate the epoll object, which can |
421 | take considerable time and thus should be avoided. |
423 | take considerable time and thus should be avoided. |
|
|
424 | |
|
|
425 | All this means that, in practice, C<EVBACKEND_SELECT> can be as fast or |
|
|
426 | faster than epoll for maybe up to a hundred file descriptors, depending on |
|
|
427 | the usage. So sad. |
422 | |
428 | |
423 | While nominally embeddable in other event loops, this feature is broken in |
429 | While nominally embeddable in other event loops, this feature is broken in |
424 | all kernel versions tested so far. |
430 | all kernel versions tested so far. |
425 | |
431 | |
426 | This backend maps C<EV_READ> and C<EV_WRITE> in the same way as |
432 | This backend maps C<EV_READ> and C<EV_WRITE> in the same way as |
… | |
… | |
1415 | else |
1421 | else |
1416 | { |
1422 | { |
1417 | // callback was invoked, but there was some activity, re-arm |
1423 | // callback was invoked, but there was some activity, re-arm |
1418 | // the watcher to fire in last_activity + 60, which is |
1424 | // the watcher to fire in last_activity + 60, which is |
1419 | // guaranteed to be in the future, so "again" is positive: |
1425 | // guaranteed to be in the future, so "again" is positive: |
1420 | w->again = timeout - now; |
1426 | w->repeat = timeout - now; |
1421 | ev_timer_again (EV_A_ w); |
1427 | ev_timer_again (EV_A_ w); |
1422 | } |
1428 | } |
1423 | } |
1429 | } |
1424 | |
1430 | |
1425 | To summarise the callback: first calculate the real timeout (defined |
1431 | To summarise the callback: first calculate the real timeout (defined |
… | |
… | |
1997 | |
2003 | |
1998 | There is no support for kqueue, as apparently it cannot be used to |
2004 | 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 |
2005 | implement this functionality, due to the requirement of having a file |
2000 | descriptor open on the object at all times, and detecting renames, unlinks |
2006 | descriptor open on the object at all times, and detecting renames, unlinks |
2001 | etc. is difficult. |
2007 | etc. is difficult. |
|
|
2008 | |
|
|
2009 | =head3 C<stat ()> is a synchronous operation |
|
|
2010 | |
|
|
2011 | Libev doesn't normally do any kind of I/O itself, and so is not blocking |
|
|
2012 | the process. The exception are C<ev_stat> watchers - those call C<stat |
|
|
2013 | ()>, which is a synchronous operation. |
|
|
2014 | |
|
|
2015 | For local paths, this usually doesn't matter: unless the system is very |
|
|
2016 | busy or the intervals between stat's are large, a stat call will be fast, |
|
|
2017 | as the path data is suually in memory already (except when starting the |
|
|
2018 | watcher). |
|
|
2019 | |
|
|
2020 | For networked file systems, calling C<stat ()> can block an indefinite |
|
|
2021 | time due to network issues, and even under good conditions, a stat call |
|
|
2022 | often takes multiple milliseconds. |
|
|
2023 | |
|
|
2024 | Therefore, it is best to avoid using C<ev_stat> watchers on networked |
|
|
2025 | paths, although this is fully supported by libev. |
2002 | |
2026 | |
2003 | =head3 The special problem of stat time resolution |
2027 | =head3 The special problem of stat time resolution |
2004 | |
2028 | |
2005 | The C<stat ()> system call only supports full-second resolution portably, |
2029 | The C<stat ()> system call only supports full-second resolution portably, |
2006 | and even on systems where the resolution is higher, most file systems |
2030 | and even on systems where the resolution is higher, most file systems |