… | |
… | |
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 practice, C<EVBACKEND_SELECT> can be as fast or |
|
|
424 | faster than epoll for maybe up to a hundred file descriptors, depending on |
|
|
425 | the usage. So sad. |
422 | |
426 | |
423 | 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 |
424 | all kernel versions tested so far. |
428 | all kernel versions tested so far. |
425 | |
429 | |
426 | 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 |
… | |
… | |
1932 | C<stat> on that path in regular intervals (or when the OS says it changed) |
1936 | C<stat> on that path in regular intervals (or when the OS says it changed) |
1933 | and sees if it changed compared to the last time, invoking the callback if |
1937 | and sees if it changed compared to the last time, invoking the callback if |
1934 | it did. |
1938 | it did. |
1935 | |
1939 | |
1936 | The path does not need to exist: changing from "path exists" to "path does |
1940 | The path does not need to exist: changing from "path exists" to "path does |
1937 | not exist" is a status change like any other. The condition "path does |
1941 | not exist" is a status change like any other. The condition "path does not |
1938 | not exist" is signified by the C<st_nlink> field being zero (which is |
1942 | exist" (or more correctly "path cannot be stat'ed") is signified by the |
1939 | otherwise always forced to be at least one) and all the other fields of |
1943 | C<st_nlink> field being zero (which is otherwise always forced to be at |
1940 | the stat buffer having unspecified contents. |
1944 | least one) and all the other fields of the stat buffer having unspecified |
|
|
1945 | contents. |
1941 | |
1946 | |
1942 | The path I<must not> end in a slash or contain special components such as |
1947 | The path I<must not> end in a slash or contain special components such as |
1943 | C<.> or C<..>. The path I<should> be absolute: If it is relative and |
1948 | C<.> or C<..>. The path I<should> be absolute: If it is relative and |
1944 | your working directory changes, then the behaviour is undefined. |
1949 | your working directory changes, then the behaviour is undefined. |
1945 | |
1950 | |
… | |
… | |
1955 | This watcher type is not meant for massive numbers of stat watchers, |
1960 | This watcher type is not meant for massive numbers of stat watchers, |
1956 | as even with OS-supported change notifications, this can be |
1961 | as even with OS-supported change notifications, this can be |
1957 | resource-intensive. |
1962 | resource-intensive. |
1958 | |
1963 | |
1959 | At the time of this writing, the only OS-specific interface implemented |
1964 | At the time of this writing, the only OS-specific interface implemented |
1960 | is the Linux inotify interface (implementing kqueue support is left as |
1965 | is the Linux inotify interface (implementing kqueue support is left as an |
1961 | an exercise for the reader. Note, however, that the author sees no way |
1966 | exercise for the reader. Note, however, that the author sees no way of |
1962 | of implementing C<ev_stat> semantics with kqueue). |
1967 | implementing C<ev_stat> semantics with kqueue, except as a hint). |
1963 | |
1968 | |
1964 | =head3 ABI Issues (Largefile Support) |
1969 | =head3 ABI Issues (Largefile Support) |
1965 | |
1970 | |
1966 | Libev by default (unless the user overrides this) uses the default |
1971 | Libev by default (unless the user overrides this) uses the default |
1967 | compilation environment, which means that on systems with large file |
1972 | compilation environment, which means that on systems with large file |
… | |
… | |
1978 | to exchange stat structures with application programs compiled using the |
1983 | to exchange stat structures with application programs compiled using the |
1979 | default compilation environment. |
1984 | default compilation environment. |
1980 | |
1985 | |
1981 | =head3 Inotify and Kqueue |
1986 | =head3 Inotify and Kqueue |
1982 | |
1987 | |
1983 | When C<inotify (7)> support has been compiled into libev (generally |
1988 | When C<inotify (7)> support has been compiled into libev and present at |
1984 | only available with Linux 2.6.25 or above due to bugs in earlier |
1989 | runtime, it will be used to speed up change detection where possible. The |
1985 | implementations) and present at runtime, it will be used to speed up |
1990 | inotify descriptor will be created lazily when the first C<ev_stat> |
1986 | change detection where possible. The inotify descriptor will be created |
1991 | watcher is being started. |
1987 | lazily when the first C<ev_stat> watcher is being started. |
|
|
1988 | |
1992 | |
1989 | Inotify presence does not change the semantics of C<ev_stat> watchers |
1993 | Inotify presence does not change the semantics of C<ev_stat> watchers |
1990 | except that changes might be detected earlier, and in some cases, to avoid |
1994 | except that changes might be detected earlier, and in some cases, to avoid |
1991 | making regular C<stat> calls. Even in the presence of inotify support |
1995 | making regular C<stat> calls. Even in the presence of inotify support |
1992 | there are many cases where libev has to resort to regular C<stat> polling, |
1996 | there are many cases where libev has to resort to regular C<stat> polling, |
1993 | but as long as the path exists, libev usually gets away without polling. |
1997 | but as long as kernel 2.6.25 or newer is used (2.6.24 and older have too |
|
|
1998 | many bugs), the path exists (i.e. stat succeeds), and the path resides on |
|
|
1999 | a local filesystem (libev currently assumes only ext2/3, jfs, reiserfs and |
|
|
2000 | xfs are fully working) libev usually gets away without polling. |
1994 | |
2001 | |
1995 | There is no support for kqueue, as apparently it cannot be used to |
2002 | There is no support for kqueue, as apparently it cannot be used to |
1996 | implement this functionality, due to the requirement of having a file |
2003 | implement this functionality, due to the requirement of having a file |
1997 | descriptor open on the object at all times, and detecting renames, unlinks |
2004 | descriptor open on the object at all times, and detecting renames, unlinks |
1998 | etc. is difficult. |
2005 | etc. is difficult. |
|
|
2006 | |
|
|
2007 | =head3 C<stat ()> is a synchronous operation |
|
|
2008 | |
|
|
2009 | Libev doesn't normally do any kind of I/O itself, and so is not blocking |
|
|
2010 | the process. The exception are C<ev_stat> watchers - those call C<stat |
|
|
2011 | ()>, which is a synchronous operation. |
|
|
2012 | |
|
|
2013 | For local paths, this usually doesn't matter: unless the system is very |
|
|
2014 | busy or the intervals between stat's are large, a stat call will be fast, |
|
|
2015 | as the path data is suually in memory already (except when starting the |
|
|
2016 | watcher). |
|
|
2017 | |
|
|
2018 | For networked file systems, calling C<stat ()> can block an indefinite |
|
|
2019 | time due to network issues, and even under good conditions, a stat call |
|
|
2020 | often takes multiple milliseconds. |
|
|
2021 | |
|
|
2022 | Therefore, it is best to avoid using C<ev_stat> watchers on networked |
|
|
2023 | paths, although this is fully supported by libev. |
1999 | |
2024 | |
2000 | =head3 The special problem of stat time resolution |
2025 | =head3 The special problem of stat time resolution |
2001 | |
2026 | |
2002 | The C<stat ()> system call only supports full-second resolution portably, |
2027 | The C<stat ()> system call only supports full-second resolution portably, |
2003 | and even on systems where the resolution is higher, most file systems |
2028 | and even on systems where the resolution is higher, most file systems |