--- libev/ev.pod 2008/11/05 21:44:21 1.215 +++ libev/ev.pod 2008/12/14 21:58:08 1.223 @@ -11,6 +11,8 @@ // a single header file is required #include + #include // for puts + // every watcher type has its own typedef'd struct // with the name ev_TYPE ev_io stdin_watcher; @@ -43,7 +45,7 @@ main (void) { // use the default event loop unless you have special needs - ev_loop *loop = ev_default_loop (0); + struct ev_loop *loop = ev_default_loop (0); // initialise an io watcher, then start it // this one will watch for stdin to become readable @@ -460,8 +462,8 @@ everywhere, so you might need to test for this. And since it is broken almost everywhere, you should only use it when you have a lot of sockets (for which it usually works), by embedding it into another event loop -(e.g. C or C) and, did I mention it, -using it only for sockets. +(e.g. C or C (but C is of course +also broken on OS X)) and, did I mention it, using it only for sockets. This backend maps C into an C kevent with C, and C into an C kevent with @@ -1421,7 +1423,7 @@ // callback was invoked, but there was some activity, re-arm // the watcher to fire in last_activity + 60, which is // guaranteed to be in the future, so "again" is positive: - w->again = timeout - now; + w->repeat = timeout - now; ev_timer_again (EV_A_ w); } } @@ -2012,7 +2014,7 @@ For local paths, this usually doesn't matter: unless the system is very busy or the intervals between stat's are large, a stat call will be fast, -as the path data is suually in memory already (except when starting the +as the path data is usually in memory already (except when starting the watcher). For networked file systems, calling C can block an indefinite @@ -2428,24 +2430,20 @@ this case you would put all the high priority stuff in one loop and all the rest in a second one, and embed the second one in the first. -As long as the watcher is active, the callback will be invoked every time -there might be events pending in the embedded loop. The callback must then -call C to make a single sweep and invoke -their callbacks (you could also start an idle watcher to give the embedded -loop strictly lower priority for example). You can also set the callback -to C<0>, in which case the embed watcher will automatically execute the -embedded loop sweep. - -As long as the watcher is started it will automatically handle events. The -callback will be invoked whenever some events have been handled. You can -set the callback to C<0> to avoid having to specify one if you are not -interested in that. - -Also, there have not currently been made special provisions for forking: -when you fork, you not only have to call C on both loops, -but you will also have to stop and restart any C watchers -yourself - but you can use a fork watcher to handle this automatically, -and future versions of libev might do just that. +As long as the watcher is active, the callback will be invoked every +time there might be events pending in the embedded loop. The callback +must then call C to make a single +sweep and invoke their callbacks (the callback doesn't need to invoke the +C function directly, it could also start an idle watcher +to give the embedded loop strictly lower priority for example). + +You can also set the callback to C<0>, in which case the embed watcher +will automatically execute the embedded loop sweep whenever necessary. + +Fork detection will be handled transparently while the C watcher +is active, i.e., the embedded loop will automatically be forked when the +embedding loop forks. In other cases, the user is responsible for calling +C on the embedded loop. Unfortunately, not all backends are embeddable: only the ones returned by C are, which, unfortunately, does not include any @@ -2891,6 +2889,36 @@ ev::io iow; iow.set (&obj); +=item w->set (object *) + +This is an B feature that might go away in a future version. + +This is a variation of a method callback - leaving out the method to call +will default the method to C, which makes it possible to use +functor objects without having to manually specify the C all +the time. Incidentally, you can then also leave out the template argument +list. + +The C method prototype must be C. + +See the method-C above for more details. + +Example: use a functor object as callback. + + struct myfunctor + { + void operator() (ev::io &w, int revents) + { + ... + } + } + + myfunctor f; + + ev::io w; + w.set (&f); + =item w->set (void *data = 0) Also sets a callback, but uses a static method or plain function as @@ -2999,6 +3027,9 @@ more on top of it. It can be found via gem servers. Its homepage is at L. +Roger Pack reports that using the link order C<-lws2_32 -lmsvcrt-ruby-190> +makes rev work even on mingw. + =item D Leandro Lucarella has written a D language binding (F) for libev, to @@ -3184,15 +3215,18 @@ supported). It will also not define any of the structs usually found in F that are not directly supported by the libev core alone. +In stanbdalone mode, libev will still try to automatically deduce the +configuration, but has to be more conservative. + =item EV_USE_MONOTONIC If defined to be C<1>, libev will try to detect the availability of the -monotonic clock option at both compile time and runtime. Otherwise no use -of the monotonic clock option will be attempted. If you enable this, you -usually have to link against librt or something similar. Enabling it when -the functionality isn't available is safe, though, although you have +monotonic clock option at both compile time and runtime. Otherwise no +use of the monotonic clock option will be attempted. If you enable this, +you usually have to link against librt or something similar. Enabling it +when the functionality isn't available is safe, though, although you have to make sure you link against any libraries where the C -function is hiding in (often F<-lrt>). +function is hiding in (often F<-lrt>). See also C. =item EV_USE_REALTIME @@ -3203,6 +3237,17 @@ (CLOCK_REALTIME, ...)> and will not normally affect correctness. See the note about libraries in the description of C, though. +=item EV_USE_CLOCK_SYSCALL + +If defined to be C<1>, libev will try to use a direct syscall instead +of calling the system-provided C function. This option +exists because on GNU/Linux, C is in C, but C +unconditionally pulls in C, slowing down single-threaded +programs needlessly. Using a direct syscall is slightly slower (in +theory), because no optimised vdso implementation can be used, but avoids +the pthread dependency. Defaults to C<1> on GNU/Linux with glibc 2.x or +higher, as it simplifies linking (no need for C<-lrt>). + =item EV_USE_NANOSLEEP If defined to be C<1>, libev will assume that C is available @@ -3227,11 +3272,11 @@ If defined to C<1>, then the select backend will use the system C structure. This is useful if libev doesn't compile due to a missing -C or C definition or it mis-guesses the bitset layout on -exotic systems. This usually limits the range of file descriptors to some -low limit such as 1024 or might have other limitations (winsocket only -allows 64 sockets). The C macro, set before compilation, might -influence the size of the C used. +C or C definition or it mis-guesses the bitset layout +on exotic systems. This usually limits the range of file descriptors to +some low limit such as 1024 or might have other limitations (winsocket +only allows 64 sockets). The C macro, set before compilation, +configures the maximum size of the C. =item EV_SELECT_IS_WINSOCKET