| … | |
… | |
| 894 | =item C<EV_ERROR> |
894 | =item C<EV_ERROR> |
| 895 | |
895 | |
| 896 | An unspecified error has occurred, the watcher has been stopped. This might |
896 | An unspecified error has occurred, the watcher has been stopped. This might |
| 897 | happen because the watcher could not be properly started because libev |
897 | happen because the watcher could not be properly started because libev |
| 898 | ran out of memory, a file descriptor was found to be closed or any other |
898 | ran out of memory, a file descriptor was found to be closed or any other |
|
|
899 | problem. Libev considers these application bugs. |
|
|
900 | |
| 899 | problem. You best act on it by reporting the problem and somehow coping |
901 | You best act on it by reporting the problem and somehow coping with the |
| 900 | with the watcher being stopped. |
902 | watcher being stopped. Note that well-written programs should not receive |
|
|
903 | an error ever, so when your watcher receives it, this usually indicates a |
|
|
904 | bug in your program. |
| 901 | |
905 | |
| 902 | Libev will usually signal a few "dummy" events together with an error, for |
906 | Libev will usually signal a few "dummy" events together with an error, for |
| 903 | example it might indicate that a fd is readable or writable, and if your |
907 | example it might indicate that a fd is readable or writable, and if your |
| 904 | callbacks is well-written it can just attempt the operation and cope with |
908 | callbacks is well-written it can just attempt the operation and cope with |
| 905 | the error from read() or write(). This will not work in multi-threaded |
909 | the error from read() or write(). This will not work in multi-threaded |
| … | |
… | |
| 1796 | to exchange stat structures with application programs compiled using the |
1800 | to exchange stat structures with application programs compiled using the |
| 1797 | default compilation environment. |
1801 | default compilation environment. |
| 1798 | |
1802 | |
| 1799 | =head3 Inotify and Kqueue |
1803 | =head3 Inotify and Kqueue |
| 1800 | |
1804 | |
| 1801 | When C<inotify (7)> support has been compiled into libev (generally only |
1805 | When C<inotify (7)> support has been compiled into libev (generally |
|
|
1806 | only available with Linux 2.6.25 or above due to bugs in earlier |
| 1802 | available with Linux) and present at runtime, it will be used to speed up |
1807 | implementations) and present at runtime, it will be used to speed up |
| 1803 | change detection where possible. The inotify descriptor will be created lazily |
1808 | change detection where possible. The inotify descriptor will be created |
| 1804 | when the first C<ev_stat> watcher is being started. |
1809 | lazily when the first C<ev_stat> watcher is being started. |
| 1805 | |
1810 | |
| 1806 | Inotify presence does not change the semantics of C<ev_stat> watchers |
1811 | Inotify presence does not change the semantics of C<ev_stat> watchers |
| 1807 | except that changes might be detected earlier, and in some cases, to avoid |
1812 | except that changes might be detected earlier, and in some cases, to avoid |
| 1808 | making regular C<stat> calls. Even in the presence of inotify support |
1813 | making regular C<stat> calls. Even in the presence of inotify support |
| 1809 | there are many cases where libev has to resort to regular C<stat> polling, |
1814 | there are many cases where libev has to resort to regular C<stat> polling, |
