--- cvsroot/EV/EV.pm 2008/10/02 12:27:55 1.105 +++ cvsroot/EV/EV.pm 2010/12/05 11:45:22 1.131 @@ -53,6 +53,15 @@ 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 @@ -70,15 +79,49 @@ and still be faster than with any other event loop currently supported in Perl. +=head2 PORTING FROM EV 3.X to 4.X + +EV version 4 introduces a number of incompatible changes summarised +here. According to the depreciation strategy used by libev, there is a +compatibility layer in place so programs should continue to run unchanged +(the XS interface lacks this layer, so programs using that one need to be +updated). + +This compatibility layer will be switched off in some future release. + +All changes relevant to Perl are renames of symbols, functions and +methods: + + EV::loop => EV::run + EV::LOOP_NONBLOCK => EV::RUN_NOWAIT + EV::LOOP_ONESHOT => EV::RUN_ONCE + + EV::unloop => EV::break + EV::UNLOOP_CANCEL => EV::BREAK_CANCEL + EV::UNLOOP_ONE => EV::BREAK_ONE + EV::UNLOOP_ALL => EV::BREAK_ALL + + EV::TIMEOUT => EV::TIMER + + EV::loop_count => EV::iteration + EV::loop_depth => EV::depth + EV::loop_verify => EV::verify + +The loop object methods corresponding to the functions above have been +similarly renamed. + +=head2 MODULE EXPORTS + +This module does not export any symbols. + =cut package EV; -no warnings; -use strict; +use common::sense; BEGIN { - our $VERSION = '3.44'; + our $VERSION = '4.01'; use XSLoader; XSLoader::load "EV", $VERSION; } @@ -115,7 +158,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 @@ -123,7 +166,7 @@ =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 @@ -197,15 +240,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] @@ -235,7 +320,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) @@ -256,7 +341,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 @@ -288,6 +373,18 @@ 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 @@ -309,10 +406,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 @@ -401,7 +497,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 :). @@ -415,7 +511,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 @@ -643,9 +739,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 @@ -879,7 +983,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): @@ -919,11 +1023,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 @@ -1000,9 +1114,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. @@ -1040,11 +1154,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 @@ -1076,9 +1190,10 @@ =head1 SEE ALSO -L (asynchronous DNS), L (makes Glib/Gtk2 use EV as -event loop), L (embed Glib into EV), L (efficient -coroutines with EV), L (asynchronous SNMP), L for +L - MakeMaker interface to XS API, L +(asynchronous DNS), L (makes Glib/Gtk2 use EV as event +loop), L (embed Glib into EV), L (efficient thread +integration), L (asynchronous SNMP), L for event-loop agnostic and portable event driven programming. =head1 AUTHOR