--- libev/ev.pod 2007/12/31 01:30:53 1.113 +++ libev/ev.pod 2008/01/09 04:15:39 1.117 @@ -405,6 +405,10 @@ descriptors a "slow" C or C backend might perform better. +On the positive side, ignoring the spurious readyness notifications, this +backend actually performed to specification in all tests and is fully +embeddable, which is a rare feat among the OS-specific backends. + =item C Try all backends (even potentially broken ones that wouldn't be tried @@ -416,9 +420,8 @@ =back If one or more of these are ored into the flags value, then only these -backends will be tried (in the reverse order as given here). If none are -specified, most compiled-in backend will be tried, usually in reverse -order of their flag values :) +backends will be tried (in the reverse order as listed here). If none are +specified, all backends in C will be tried. The most typical usage is like this: @@ -577,7 +580,7 @@ were used, or there are no active watchers, return, otherwise continue with step *. -Example: Queue some jobs and then loop until no events are outsanding +Example: Queue some jobs and then loop until no events are outstanding anymore. ... queue jobs here, make sure they register event watchers as long @@ -592,6 +595,8 @@ C, which will make the innermost C call return, or C, which will make all nested C calls return. +This "unloop state" will be cleared when entering C again. + =item ev_ref (loop) =item ev_unref (loop) @@ -605,7 +610,9 @@ visible to the libev user and should not keep C from exiting if no event watchers registered by it are active. It is also an excellent way to do this for generic recurring timers or from within third-party -libraries. Just remember to I and I. +libraries. Just remember to I and I +(but only if the watcher wasn't active before, or was active before, +respectively). Example: Create a signal watcher, but keep it from keeping C running when nothing else is active.