… | |
… | |
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 |
… | |
… | |
1932 | C<stat> on that path in regular intervals (or when the OS says it changed) |
1935 | 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 |
1936 | and sees if it changed compared to the last time, invoking the callback if |
1934 | it did. |
1937 | it did. |
1935 | |
1938 | |
1936 | The path does not need to exist: changing from "path exists" to "path does |
1939 | 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 |
1940 | 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 |
1941 | 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 |
1942 | C<st_nlink> field being zero (which is otherwise always forced to be at |
1940 | the stat buffer having unspecified contents. |
1943 | least one) and all the other fields of the stat buffer having unspecified |
|
|
1944 | contents. |
1941 | |
1945 | |
1942 | The path I<must not> end in a slash or contain special components such as |
1946 | 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 |
1947 | C<.> or C<..>. The path I<should> be absolute: If it is relative and |
1944 | your working directory changes, then the behaviour is undefined. |
1948 | your working directory changes, then the behaviour is undefined. |
1945 | |
1949 | |
… | |
… | |
1955 | This watcher type is not meant for massive numbers of stat watchers, |
1959 | This watcher type is not meant for massive numbers of stat watchers, |
1956 | as even with OS-supported change notifications, this can be |
1960 | as even with OS-supported change notifications, this can be |
1957 | resource-intensive. |
1961 | resource-intensive. |
1958 | |
1962 | |
1959 | At the time of this writing, the only OS-specific interface implemented |
1963 | At the time of this writing, the only OS-specific interface implemented |
1960 | is the Linux inotify interface (implementing kqueue support is left as |
1964 | 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 |
1965 | exercise for the reader. Note, however, that the author sees no way of |
1962 | of implementing C<ev_stat> semantics with kqueue). |
1966 | implementing C<ev_stat> semantics with kqueue, except as a hint). |
1963 | |
1967 | |
1964 | =head3 ABI Issues (Largefile Support) |
1968 | =head3 ABI Issues (Largefile Support) |
1965 | |
1969 | |
1966 | Libev by default (unless the user overrides this) uses the default |
1970 | Libev by default (unless the user overrides this) uses the default |
1967 | compilation environment, which means that on systems with large file |
1971 | compilation environment, which means that on systems with large file |
… | |
… | |
1978 | to exchange stat structures with application programs compiled using the |
1982 | to exchange stat structures with application programs compiled using the |
1979 | default compilation environment. |
1983 | default compilation environment. |
1980 | |
1984 | |
1981 | =head3 Inotify and Kqueue |
1985 | =head3 Inotify and Kqueue |
1982 | |
1986 | |
1983 | When C<inotify (7)> support has been compiled into libev (generally |
1987 | 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 |
1988 | 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 |
1989 | inotify descriptor will be created lazily when the first C<ev_stat> |
1986 | change detection where possible. The inotify descriptor will be created |
1990 | watcher is being started. |
1987 | lazily when the first C<ev_stat> watcher is being started. |
|
|
1988 | |
1991 | |
1989 | Inotify presence does not change the semantics of C<ev_stat> watchers |
1992 | 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 |
1993 | 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 |
1994 | 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, |
1995 | 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. |
1996 | but as long as kernel 2.6.25 or newer is used (2.6.24 and older have too |
|
|
1997 | many bugs), the path exists (i.e. stat succeeds), and the path resides on |
|
|
1998 | a local filesystem (libev currently assumes only ext2/3, jfs, reiserfs and |
|
|
1999 | xfs are fully working) libev usually gets away without polling. |
1994 | |
2000 | |
1995 | 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 |
1996 | implement this functionality, due to the requirement of having a file |
2002 | implement this functionality, due to the requirement of having a file |
1997 | 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 |
1998 | etc. is difficult. |
2004 | etc. is difficult. |
|
|
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. |
1999 | |
2023 | |
2000 | =head3 The special problem of stat time resolution |
2024 | =head3 The special problem of stat time resolution |
2001 | |
2025 | |
2002 | The C<stat ()> system call only supports full-second resolution portably, |
2026 | The C<stat ()> system call only supports full-second resolution portably, |
2003 | 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 |