--- cvsroot/Coro/Coro.pm	2007/01/05 16:55:01	1.105
+++ cvsroot/Coro/Coro.pm	2007/01/05 20:00:49	1.108
@@ -212,7 +212,10 @@
 that might have executed other code already (which can be good or bad :).
 
 Also, the block is executed in an C<eval> context and a warning will be
-issued in case of an exception instead of terminating the program, as C<async> does.
+issued in case of an exception instead of terminating the program, as
+C<async> does. As the coroutine is being reused, stuff like C<on_destroy>
+will not work in the expected way, unless you call terminate or cancel,
+which somehow defeats the purpose of pooling.
 
 The priority will be reset to C<0> after each job, otherwise the coroutine
 will be re-used "as-is".
@@ -244,8 +247,8 @@
 
       $current->prio (0);
       schedule;
-   }        
-}           
+   }
+}
 
 sub async_pool(&@) {
    # this is also inlined into the unlock_scheduler
@@ -289,11 +292,15 @@
 ready queue and calls C<schedule>, which has the effect of giving up the
 current "timeslice" to other coroutines of the same or higher priority.
 
+Returns true if at least one coroutine switch has happened.
+
 =item Coro::cede_notself
 
 Works like cede, but is not exported by default and will cede to any
 coroutine, regardless of priority, once.
 
+Returns true if at least one coroutine switch has happened.
+
 =item terminate [arg...]
 
 Terminates the current coroutine with the given status values (see L<cancel>).