--- cvsroot/EV/EV.pm	2008/10/30 08:10:38	1.107
+++ cvsroot/EV/EV.pm	2009/12/01 13:56:33	1.124
@@ -78,11 +78,10 @@
 
 package EV;
 
-no warnings;
-use strict;
+use common::sense;
 
 BEGIN {
-   our $VERSION = '3.48';
+   our $VERSION = '3.8';
    use XSLoader;
    XSLoader::load "EV", $VERSION;
 }
@@ -119,7 +118,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<embed> 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
@@ -127,7 +126,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<ev_loop_new ()> function description in the libev documentation
@@ -201,15 +200,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<EV::now> in the progress. This is a costly operation and
+is usually done automatically within C<EV::loop>.
+
+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<suspend>
+in your C<SIGTSTP> handler, sending yourself a C<SIGSTOP> and calling
+C<resume> directly afterwards to resume timer processing.
+
+Effectively, all C<timer> watchers will be delayed by the time spend
+between C<suspend> and C<resume>, and all C<periodic> watchers
+will be rescheduled (that is, they will lose any events that would have
+occured while suspended).
+
+After calling C<suspend> you B<must not> call I<any> function on the given
+loop other than C<resume>, and you B<must not> call C<resume>
+without a previous call to C<suspend>.
+
+Calling C<suspend>/C<resume> has the side effect of updating the event
+loop time (see C<now_update>).
+
 =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]
 
@@ -239,7 +280,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)
 
@@ -292,6 +333,18 @@
 L<http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#FUNCTIONS_CONTROLLING_THE_EVENT_LOOP>
 (locally installed as F<EV::libev>) 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
 
 
@@ -313,7 +366,7 @@
 
 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).
@@ -405,7 +458,7 @@
 
 Normally, C<EV::loop> 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<EV::loop> once and when it returns you know that all your jobs are
 finished (or they forgot to register some watchers for their task :).
 
@@ -419,7 +472,7 @@
 In this case you can clear the keepalive status, which means that even
 though your watcher is active, it won't keep C<EV::loop> 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
@@ -647,9 +700,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<kill> 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
@@ -923,7 +984,7 @@
    };
 
 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<check_ns> variant doesn't start (activate) the newly created watcher.
@@ -1004,9 +1065,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.
 
@@ -1044,11 +1105,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<Coro::EV>).
 
 =head1 FORK