[ViewVC] Diff of: cvs/AnyEvent-Fork-Pool/Pool.pm

Comparing AnyEvent-Fork-Pool/Pool.pm (file contents):
Revision 1.13 by root, Sun Apr 28 14:27:31 2013 UTC vs.
Revision 1.14 by root, Sun Oct 26 16:22:38 2014 UTC

 AnyEvent::Fork::Pool - simple process pool manager on top of AnyEvent::Fork
 =head1 SYNOPSIS
    use AnyEvent;
+   use AnyEvent::Fork;
    use AnyEvent::Fork::Pool;
-   # use AnyEvent::Fork is not needed
    # all possible parameters shown, with default values
    my $pool = AnyEvent::Fork
       ->new
       ->require ("MyWorker")
 use Guard ();
 use Array::Heap ();
 use AnyEvent;
-# explicit version on next line, as some cpan-testers test with the 0.1 version,
-# ignoring dependencies, and this line will at least give a clear indication of that.
-use AnyEvent::Fork 0.6; # we don't actually depend on it, this is for convenience
 use AnyEvent::Fork::RPC;
 # these are used for the first and last argument of events
 # in the hope of not colliding. yes, I don't like it either,
 # but didn't come up with an obviously better alternative.
 =item $cpus = AnyEvent::Fork::Pool::ncpu [$default_cpus]
 =item ($cpus, $eus) = AnyEvent::Fork::Pool::ncpu [$default_cpus]
-Tries to detect the number of CPUs (C<$cpus> often called cpu cores
+Tries to detect the number of CPUs (C<$cpus> often called CPU cores
 nowadays) and execution units (C<$eus>) which include e.g. extra
 hyperthreaded units). When C<$cpus> cannot be determined reliably,
 C<$default_cpus> is returned for both values, or C<1> if it is missing.
 For normal CPU bound uses, it is wise to have as many worker processes
 hyperthreading is usually detrimental to performance, but in those rare
 cases where that really helps it might be beneficial to use more workers
 (C<$eus>).
 Currently, F</proc/cpuinfo> is parsed on GNU/Linux systems for both
-C<$cpus> and C<$eu>, and on {Free,Net,Open}BSD, F<sysctl -n hw.ncpu> is
+C<$cpus> and C<$eus>, and on {Free,Net,Open}BSD, F<sysctl -n hw.ncpu> is
 used for C<$cpus>.
-Example: create a worker pool with as many workers as cpu cores, or C<2>,
+Example: create a worker pool with as many workers as CPU cores, or C<2>,
 if the actual number could not be determined.
    $fork->AnyEvent::Fork::Pool::run ("myworker::function",
       max => (scalar AnyEvent::Fork::Pool::ncpu 2),
    );
 =item AnyEvent::Fork::Pool::retire ()
 This function sends an event to the parent process to request retirement:
 the worker is removed from the pool and no new jobs will be sent to it,
-but it has to handle the jobs that are already queued.
+but it still has to handle the jobs that are already queued.
 The parentheses are part of the syntax: the function usually isn't defined
 when you compile your code (because that happens I<before> handing the
 template process over to C<AnyEvent::Fork::Pool::run>, so you need the
 empty parentheses to tell Perl that the function is indeed a function.
 Retiring a worker can be useful to gracefully shut it down when the worker
-deems this useful. For example, after executing a job, one could check
+deems this useful. For example, after executing a job, it could check the
-the process size or the number of jobs handled so far, and if either is
+process size or the number of jobs handled so far, and if either is too
-too high, the worker could ask to get retired, to avoid memory leaks to
+high, the worker could request to be retired, to avoid memory leaks to
 accumulate.
-Example: retire a worker after it has handled roughly 100 requests.
+Example: retire a worker after it has handled roughly 100 requests. It
+doesn't matter whether you retire at the beginning or end of your request,
+as the worker will continue to handle some outstanding requests. Likewise,
+it's ok to call retire multiple times.
    my $count = 0;
    sub my::worker {
 =back
 =head1 POOL PARAMETERS RECIPES
-This section describes some recipes for pool paramaters. These are mostly
+This section describes some recipes for pool parameters. These are mostly
 meant for the synchronous RPC backend, as the asynchronous RPC backend
 changes the rules considerably, making workers themselves responsible for
 their scheduling.
 =over 4
 =item high throughput, I/O bound jobs - set load >= 2, max = 1, or very high
 When your jobs are I/O bound, using more workers usually boils down to
 higher throughput, depending very much on your actual workload - sometimes
 having only one worker is best, for example, when you read or write big
-files at maixmum speed, as a second worker will increase seek times.
+files at maximum speed, as a second worker will increase seek times.
 =back
 =head1 EXCEPTIONS
-The same "policy" as with L<AnyEvent::Fork::RPC> applies - exceptins will
+The same "policy" as with L<AnyEvent::Fork::RPC> applies - exceptions
-not be caught, and exceptions in both worker and in callbacks causes
+will not be caught, and exceptions in both worker and in callbacks causes
 undesirable or undefined behaviour.
 =head1 SEE ALSO
 L<AnyEvent::Fork>, to create the processes in the first place.

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing AnyEvent-Fork-Pool/Pool.pm (file contents): Revision 1.13 by root, Sun Apr 28 14:27:31 2013 UTC vs. Revision 1.14 by root, Sun Oct 26 16:22:38 2014 UTC

Diff Legend

Comparing AnyEvent-Fork-Pool/Pool.pm (file contents):
Revision 1.13 by root, Sun Apr 28 14:27:31 2013 UTC vs.
Revision 1.14 by root, Sun Oct 26 16:22:38 2014 UTC