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

Comparing libev/ev.pod (file contents):
Revision 1.193 by root, Wed Oct 1 04:25:25 2008 UTC vs.
Revision 1.197 by root, Tue Oct 21 20:52:30 2008 UTC

685C<EVUNLOOP_ONE>, which will make the innermost C<ev_loop> call return, or 685C<EVUNLOOP_ONE>, which will make the innermost C<ev_loop> call return, or
686C<EVUNLOOP_ALL>, which will make all nested C<ev_loop> calls return. 686C<EVUNLOOP_ALL>, which will make all nested C<ev_loop> calls return.
687 687
688This "unloop state" will be cleared when entering C<ev_loop> again. 688This "unloop state" will be cleared when entering C<ev_loop> again.
689 689
690It is safe to call C<ev_unloop> from otuside any C<ev_loop> calls.
691
690=item ev_ref (loop) 692=item ev_ref (loop)
691 693
692=item ev_unref (loop) 694=item ev_unref (loop)
693 695
694Ref/unref can be used to add or remove a reference count on the event 696Ref/unref can be used to add or remove a reference count on the event
892=item C<EV_ERROR> 894=item C<EV_ERROR>
893 895
894An unspecified error has occurred, the watcher has been stopped. This might 896An unspecified error has occurred, the watcher has been stopped. This might
895happen because the watcher could not be properly started because libev 897happen because the watcher could not be properly started because libev
896ran out of memory, a file descriptor was found to be closed or any other 898ran out of memory, a file descriptor was found to be closed or any other
899problem. Libev considers these application bugs.
900
897problem. You best act on it by reporting the problem and somehow coping 901You best act on it by reporting the problem and somehow coping with the
898with the watcher being stopped. 902watcher being stopped. Note that well-written programs should not receive
903an error ever, so when your watcher receives it, this usually indicates a
904bug in your program.
899 905
900Libev will usually signal a few "dummy" events together with an error, for 906Libev will usually signal a few "dummy" events together with an error, for
901example it might indicate that a fd is readable or writable, and if your 907example it might indicate that a fd is readable or writable, and if your
902callbacks is well-written it can just attempt the operation and cope with 908callbacks is well-written it can just attempt the operation and cope with
903the error from read() or write(). This will not work in multi-threaded 909the error from read() or write(). This will not work in multi-threaded
967 973
968 ev_io_start (EV_DEFAULT_UC, &w); 974 ev_io_start (EV_DEFAULT_UC, &w);
969 975
970=item C<ev_TYPE_stop> (loop *, ev_TYPE *watcher) 976=item C<ev_TYPE_stop> (loop *, ev_TYPE *watcher)
971 977
972Stops the given watcher again (if active) and clears the pending 978Stops the given watcher if active, and clears the pending status (whether
979the watcher was active or not).
980
973status. It is possible that stopped watchers are pending (for example, 981It is possible that stopped watchers are pending - for example,
974non-repeating timers are being stopped when they become pending), but 982non-repeating timers are being stopped when they become pending - but
975C<ev_TYPE_stop> ensures that the watcher is neither active nor pending. If 983calling C<ev_TYPE_stop> ensures that the watcher is neither active nor
976you want to free or reuse the memory used by the watcher it is therefore a 984pending. If you want to free or reuse the memory used by the watcher it is
977good idea to always call its C<ev_TYPE_stop> function. 985therefore a good idea to always call its C<ev_TYPE_stop> function.
978 986
979=item bool ev_is_active (ev_TYPE *watcher) 987=item bool ev_is_active (ev_TYPE *watcher)
980 988
981Returns a true value iff the watcher is active (i.e. it has been started 989Returns a true value iff the watcher is active (i.e. it has been started
982and not yet been stopped). As long as a watcher is active you must not modify 990and not yet been stopped). As long as a watcher is active you must not modify
1792to exchange stat structures with application programs compiled using the 1800to exchange stat structures with application programs compiled using the
1793default compilation environment. 1801default compilation environment.
1794 1802
1795=head3 Inotify and Kqueue 1803=head3 Inotify and Kqueue
1796 1804
1797When C<inotify (7)> support has been compiled into libev (generally only 1805When C<inotify (7)> support has been compiled into libev (generally
1806only available with Linux 2.6.25 or above due to bugs in earlier
1798available with Linux) and present at runtime, it will be used to speed up 1807implementations) and present at runtime, it will be used to speed up
1799change detection where possible. The inotify descriptor will be created lazily 1808change detection where possible. The inotify descriptor will be created
1800when the first C<ev_stat> watcher is being started. 1809lazily when the first C<ev_stat> watcher is being started.
1801 1810
1802Inotify presence does not change the semantics of C<ev_stat> watchers 1811Inotify presence does not change the semantics of C<ev_stat> watchers
1803except that changes might be detected earlier, and in some cases, to avoid 1812except that changes might be detected earlier, and in some cases, to avoid
1804making regular C<stat> calls. Even in the presence of inotify support 1813making regular C<stat> calls. Even in the presence of inotify support
1805there are many cases where libev has to resort to regular C<stat> polling, 1814there are many cases where libev has to resort to regular C<stat> polling,

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines