ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/libev/ev.pod
(Generate patch)

Comparing libev/ev.pod (file contents):
Revision 1.211 by root, Mon Nov 3 14:34:16 2008 UTC vs.
Revision 1.217 by root, Mon Nov 17 03:37:08 2008 UTC

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;
417i.e. keep at least one watcher active per fd at all times. Stopping and 419i.e. keep at least one watcher active per fd at all times. Stopping and
418starting a watcher (without re-setting it) also usually doesn't cause 420starting a watcher (without re-setting it) also usually doesn't cause
419extra overhead. A fork can both result in spurious notifications as well 421extra overhead. A fork can both result in spurious notifications as well
420as in libev having to destroy and recreate the epoll object, which can 422as in libev having to destroy and recreate the epoll object, which can
421take considerable time and thus should be avoided. 423take considerable time and thus should be avoided.
424
425All this means that, in practice, C<EVBACKEND_SELECT> can be as fast or
426faster than epoll for maybe up to a hundred file descriptors, depending on
427the usage. So sad.
422 428
423While nominally embeddable in other event loops, this feature is broken in 429While nominally embeddable in other event loops, this feature is broken in
424all kernel versions tested so far. 430all kernel versions tested so far.
425 431
426This backend maps C<EV_READ> and C<EV_WRITE> in the same way as 432This 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
1425To summarise the callback: first calculate the real timeout (defined 1431To summarise the callback: first calculate the real timeout (defined
1997 2003
1998There is no support for kqueue, as apparently it cannot be used to 2004There is no support for kqueue, as apparently it cannot be used to
1999implement this functionality, due to the requirement of having a file 2005implement this functionality, due to the requirement of having a file
2000descriptor open on the object at all times, and detecting renames, unlinks 2006descriptor open on the object at all times, and detecting renames, unlinks
2001etc. is difficult. 2007etc. is difficult.
2008
2009=head3 C<stat ()> is a synchronous operation
2010
2011Libev doesn't normally do any kind of I/O itself, and so is not blocking
2012the process. The exception are C<ev_stat> watchers - those call C<stat
2013()>, which is a synchronous operation.
2014
2015For local paths, this usually doesn't matter: unless the system is very
2016busy or the intervals between stat's are large, a stat call will be fast,
2017as the path data is suually in memory already (except when starting the
2018watcher).
2019
2020For networked file systems, calling C<stat ()> can block an indefinite
2021time due to network issues, and even under good conditions, a stat call
2022often takes multiple milliseconds.
2023
2024Therefore, it is best to avoid using C<ev_stat> watchers on networked
2025paths, 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
2005The C<stat ()> system call only supports full-second resolution portably, 2029The C<stat ()> system call only supports full-second resolution portably,
2006and even on systems where the resolution is higher, most file systems 2030and even on systems where the resolution is higher, most file systems

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines