… | |
… | |
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 |
… | |
… | |
969 | |
973 | |
970 | ev_io_start (EV_DEFAULT_UC, &w); |
974 | ev_io_start (EV_DEFAULT_UC, &w); |
971 | |
975 | |
972 | =item C<ev_TYPE_stop> (loop *, ev_TYPE *watcher) |
976 | =item C<ev_TYPE_stop> (loop *, ev_TYPE *watcher) |
973 | |
977 | |
974 | Stops the given watcher again (if active) and clears the pending |
978 | Stops the given watcher if active, and clears the pending status (whether |
|
|
979 | the watcher was active or not). |
|
|
980 | |
975 | status. It is possible that stopped watchers are pending (for example, |
981 | It is possible that stopped watchers are pending - for example, |
976 | non-repeating timers are being stopped when they become pending), but |
982 | non-repeating timers are being stopped when they become pending - but |
977 | C<ev_TYPE_stop> ensures that the watcher is neither active nor pending. If |
983 | calling C<ev_TYPE_stop> ensures that the watcher is neither active nor |
978 | you want to free or reuse the memory used by the watcher it is therefore a |
984 | pending. If you want to free or reuse the memory used by the watcher it is |
979 | good idea to always call its C<ev_TYPE_stop> function. |
985 | therefore a good idea to always call its C<ev_TYPE_stop> function. |
980 | |
986 | |
981 | =item bool ev_is_active (ev_TYPE *watcher) |
987 | =item bool ev_is_active (ev_TYPE *watcher) |
982 | |
988 | |
983 | Returns a true value iff the watcher is active (i.e. it has been started |
989 | Returns a true value iff the watcher is active (i.e. it has been started |
984 | and not yet been stopped). As long as a watcher is active you must not modify |
990 | and not yet been stopped). As long as a watcher is active you must not modify |
… | |
… | |
1794 | to exchange stat structures with application programs compiled using the |
1800 | to exchange stat structures with application programs compiled using the |
1795 | default compilation environment. |
1801 | default compilation environment. |
1796 | |
1802 | |
1797 | =head3 Inotify and Kqueue |
1803 | =head3 Inotify and Kqueue |
1798 | |
1804 | |
1799 | 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 |
1800 | 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 |
1801 | change detection where possible. The inotify descriptor will be created lazily |
1808 | change detection where possible. The inotify descriptor will be created |
1802 | when the first C<ev_stat> watcher is being started. |
1809 | lazily when the first C<ev_stat> watcher is being started. |
1803 | |
1810 | |
1804 | 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 |
1805 | 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 |
1806 | 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 |
1807 | 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, |