--- cvsroot/EV/EV.pm 2008/07/12 22:19:22 1.101 +++ cvsroot/EV/EV.pm 2010/10/21 02:46:59 1.128 @@ -53,15 +53,25 @@ EV::loop EV::LOOP_ONESHOT; # block until at least one event could be handled EV::loop EV::LOOP_NONBLOCK; # try to handle same events, but do not block +=head1 BEFORE YOU START USING THIS MODULE + +If you only need timer, I/O, signal, child and idle watchers and not the +advanced functionality of this module, consider using L instead, +specifically the simplified API described in L. + +When used with EV as backend, the L API is as fast as the native L +API, but your programs/modules will still run with many other event loops. + =head1 DESCRIPTION This module provides an interface to libev (L). While the documentation -below is comprehensive, one might also consult the documentation of libev -itself (L) for more -subtle details on watcher semantics or some discussion on the available -backends, or how to force a specific backend with C, or just -about in any case because it has much more detailed information. +below is comprehensive, one might also consult the documentation of +libev itself (L or +F) for more subtle details on watcher semantics or some +discussion on the available backends, or how to force a specific backend +with C, or just about in any case because it has much more +detailed information. This module is very fast and scalable. It is actually so fast that you can use it through the L module, stay portable to other event @@ -69,15 +79,18 @@ and still be faster than with any other event loop currently supported in Perl. +=head2 MODULE EXPORTS + +This module does not export any symbols. + =cut package EV; -no warnings; -use strict; +use common::sense; BEGIN { - our $VERSION = '3.431'; + our $VERSION = '4.00'; use XSLoader; XSLoader::load "EV", $VERSION; } @@ -114,7 +127,7 @@ For specific programs you can create additional event loops dynamically. -If you want to take avdantage of kqueue (which often works properly for +If you want to take advantage of kqueue (which often works properly for sockets only) even though the default loop doesn't enable it, you can I a kqueue loop into the default loop: running the default loop will then also service the kqueue loop to some extent. See the example in @@ -122,18 +135,20 @@ =over 4 -=item $loop = new EV::loop [$flags] +=item $loop = new EV::Loop [$flags] -Create a new event loop as per the specified flags. Please refer to the -C function description in the libev documentation -(L) -for more info. +Create a new event loop as per the specified flags. Please refer to +the C function description in the libev documentation +(L, +or locally-installed as F manpage) for more info. The loop will automatically be destroyed when it is no longer referenced by any watcher and the loop object goes out of scope. -Using C is recommended, as only the default event loop -is protected by this module. +If you are not embedding the loop, then Using C +is recommended, as only the default event loop is protected by this +module. If you I embedding this loop in the default loop, this is not +necessary, as C automatically does the right thing on fork. =item $loop->loop_fork @@ -194,15 +209,57 @@ =item $time = $loop->now Returns the time the last event loop iteration has been started. This -is the time that (relative) timers are based on, and refering to it is +is the time that (relative) timers are based on, and referring to it is usually faster then calling EV::time. +=item EV::now_update + +=item $loop->now_update + +Establishes the current time by querying the kernel, updating the time +returned by C in the progress. This is a costly operation and +is usually done automatically within C. + +This function is rarely useful, but when some event callback runs for a +very long time without entering the event loop, updating libev's idea of +the current time is a good idea. + +=item EV::suspend + +=item $loop->suspend + +=item EV::resume + +=item $loop->resume + +These two functions suspend and resume a loop, for use when the loop is +not used for a while and timeouts should not be processed. + +A typical use case would be an interactive program such as a game: When +the user presses C<^Z> to suspend the game and resumes it an hour later it +would be best to handle timeouts as if no time had actually passed while +the program was suspended. This can be achieved by calling C +in your C handler, sending yourself a C and calling +C directly afterwards to resume timer processing. + +Effectively, all C watchers will be delayed by the time spend +between C and C, and all C watchers +will be rescheduled (that is, they will lose any events that would have +occured while suspended). + +After calling C you B call I function on the given +loop other than C, and you B call C +without a previous call to C. + +Calling C/C has the side effect of updating the event +loop time (see C). + =item $backend = EV::backend =item $backend = $loop->backend -Returns an integer describing the backend used by libev (EV::METHOD_SELECT -or EV::METHOD_EPOLL). +Returns an integer describing the backend used by libev (EV::BACKEND_SELECT +or EV::BACKEND_EPOLL). =item EV::loop [$flags] @@ -232,7 +289,7 @@ =item $count = $loop->loop_count Return the number of times the event loop has polled for new -events. Sometiems useful as a generation counter. +events. Sometimes useful as a generation counter. =item EV::once $fh_or_undef, $events, $timeout, $cb->($revents) @@ -253,7 +310,7 @@ When an error occurs or either the timeout or I/O watcher triggers, then the callback will be called with the received event set (in general you can expect it to be a combination of C, C, -C and C). +C and C). EV::once doesn't return anything: the watchers stay active till either of them triggers, then they will be stopped and freed, and the callback @@ -282,8 +339,20 @@ These advanced functions set the minimum block interval when polling for I/O events and the minimum wait interval for timer events. See the libev documentation at -L for -a more detailed discussion. +L +(locally installed as F) for a more detailed discussion. + +=item $count = EV::pending_count + +=item $count = $loop->pending_count + +Returns the number of currently pending watchers. + +=item EV::invoke_pending + +=item $loop->invoke_pending + +Invoke all currently pending watchers. =back @@ -306,10 +375,9 @@ Each watcher type has its associated bit in revents, so you can use the same callback for multiple watchers. The event mask is named after the -type, i..e. EV::child sets EV::CHILD, EV::prepare sets EV::PREPARE, +type, i.e. EV::child sets EV::CHILD, EV::prepare sets EV::PREPARE, EV::periodic sets EV::PERIODIC and so on, with the exception of I/O events -(which can set both EV::READ and EV::WRITE bits), and EV::timer (which -uses EV::TIMEOUT). +(which can set both EV::READ and EV::WRITE bits). In the rare case where one wants to create a watcher but not start it at the same time, each constructor has a variant with a trailing C<_ns> in @@ -398,7 +466,7 @@ Normally, C will return when there are no active watchers (which is a "deadlock" because no progress can be made anymore). This is -convinient because it allows you to start your watchers (and your jobs), +convenient because it allows you to start your watchers (and your jobs), call C once and when it returns you know that all your jobs are finished (or they forgot to register some watchers for their task :). @@ -412,7 +480,7 @@ In this case you can clear the keepalive status, which means that even though your watcher is active, it won't keep C from returning. -The initial value for keepalive is true (enabled), and you cna change it +The initial value for keepalive is true (enabled), and you can change it any time. Example: Register an I/O watcher for some UDP socket but do not keep the @@ -640,9 +708,17 @@ =item $w = EV::signal_ns $signal, $callback +=item $w = $loop->signal ($signal, $callback) + +=item $w = $loop->signal_ns ($signal, $callback) + Call the callback when $signal is received (the signal can be specified by number or by name, just as with C or C<%SIG>). +Only one event loop can grab a given signal - attempting to grab the same +signal from two EV loops will crash the program immediately or cause data +corruption. + EV will grab the signal for the process (the kernel only allows one component to receive a signal at a time) when you start a signal watcher, and removes it again when you stop it. Perl does the same when you @@ -876,7 +952,7 @@ Call the callback just after the process wakes up again (after it has gathered events), but before any other callbacks have been invoked. -This is used to integrate other event-based software into the EV +This can be used to integrate other event-based software into the EV mainloop: You register a prepare callback and in there, you create io and timer watchers as required by the other software. Here is a real-world example of integrating Net::SNMP (with some details left out): @@ -916,11 +992,21 @@ }; The callbacks of the created watchers will not be called as the watchers -are destroyed before this cna happen (remember EV::check gets called +are destroyed before this can happen (remember EV::check gets called first). The C variant doesn't start (activate) the newly created watcher. +=item EV::CHECK constant issues + +Like all other watcher types, there is a bitmask constant for use in +C<$revents> and other places. The C is special as it has +the same name as the C sub called by Perl. This doesn't cause +big issues on newer perls (beginning with 5.8.9), but it means thatthe +constant must be I, i.e. runtime calls will not work. That means +that as long as you always C and then C you are on the +safe side. + =back @@ -957,7 +1043,7 @@ See the libev documentation at L -for more details. +(locally installed as F) for more details. In short, this watcher is most useful on BSD systems without working kqueue to still be able to handle a large number of sockets: @@ -997,9 +1083,9 @@ =head3 ASYNC WATCHERS - how to wake up another event loop -Async watchers are provided by EV, but have little use in perl directly, as perl -neither supports threads nor direct access to signal handlers or other -contexts where they could be of value. +Async watchers are provided by EV, but have little use in perl directly, +as perl neither supports threads running in parallel nor direct access to +signal handlers or other contexts where they could be of value. It is, however, possible to use them from the XS level. @@ -1037,11 +1123,11 @@ This ensures that perl gets into control for a short time to handle any pending signals, and also ensures (slightly) slower overall operation. -=head1 THREADS +=head1 ITHREADS -Threads are not supported by this module in any way. Perl pseudo-threads -is evil stuff and must die. As soon as Perl gains real threads I will work -on thread support for it. +Ithreads are not supported by this module in any way. Perl pseudo-threads +is evil stuff and must die. Real threads as provided by Coro are fully +supported (and enhanced support is available via L). =head1 FORK