--- cvsroot/EV/EV.pm	2009/03/14 16:24:27	1.113
+++ cvsroot/EV/EV.pm	2009/12/31 06:59:47	1.125
@@ -78,11 +78,10 @@
 
 package EV;
 
-no warnings;
-use strict;
+use common::sense;
 
 BEGIN {
-   our $VERSION = '3.53';
+   our $VERSION = '3.9';
    use XSLoader;
    XSLoader::load "EV", $VERSION;
 }
@@ -204,6 +203,48 @@
 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
@@ -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
 
 
@@ -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 :).
 
@@ -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
@@ -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