=head1 NAME AnyEvent::Fork::Pool - simple process pool manager on top of AnyEvent::Fork =head1 SYNOPSIS use AnyEvent; use AnyEvent::Fork::Pool; # use AnyEvent::Fork is not needed # all parameters with default values my $pool = new AnyEvent::Fork::Pool "MyWorker::run", # pool management min => 0, # minimum # of processes max => 4, # maximum # of processes max_queue => 2, # queue at most this number of jobs per process min_delay => 0, # wait this many seconds before starting a new process min_idle => 0, # try to have at least this amount of idle processes max_idle => 1, # at most this many idle processes idle_time => 1, # wait this many seconds before killing an idle process on_destroy => (my $finish = AE::cv), # template process template => AnyEvent::Fork->new, # the template process to use require => [MyWorker::], # module(s) to load eval => "# perl code to execute in template", # parameters passed to AnyEvent::Fork::RPC async => 0, on_error => sub { die "FATAL: $_[0]\n" }, on_event => sub { my @ev = @_ }, init => "MyWorker::init", serialiser => $AnyEvent::Fork::RPC::STRING_SERIALISER, ; for (1..10) { $pool->call (doit => $_, sub { print "MyWorker::run returned @_\n"; }); } undef $pool; $finish->recv; =head1 DESCRIPTION This module uses processes created via L and the RPC protocol implement in L to create a load-balanced pool of processes that handles jobs. Understanding of L is helpful but not critical to be able to use this module, but a thorough understanding of L is, as it defines the actual API that needs to be implemented in the children. =head1 EXAMPLES =head1 PARENT USAGE =over 4 =cut package AnyEvent::Fork::Pool; use common::sense; use Scalar::Util (); use Array::Heap (); use AnyEvent; use AnyEvent::Fork; # we don't actually depend on it, this is for convenience use AnyEvent::Fork::RPC; my $magic0 = ':t6Z@HK1N%Dx@_7?=~-7NQgWDdAs6a,jFN=wLO0*jD*1%P'; my $magic2 = '<~53rexz.U`!]X[A235^"fyEoiTF\T~oH1l/N6+Djep9b~bI9`\1x%B~vWO1q*'; our $VERSION = 0.1; =item my $rpc = new AnyEvent::Fork::Pool $function, [key => value...] Creates a new pool object with the specified C<$function> as function (name) to call for each request. A pool consists of a template process that contains the code and data that the worker processes need. And a number of worker processes that have been forked off of that template process. You can supply your own template process, or tell C to create one. A relatively large number of key/value pairs can be specified to influence the behaviour. They are grouped into the categories "pool management", "template process" and "rpc parameters". =over 4 =item Pool Management The pool consists of a certain number of worker processes. These options decide how many of these processes exist and when they are started and stopp.ed =over 4 =item min => $count (default: 0) The minimum number of processes in the pool, in addition to the template process. Even when idle, there will never be fewer than this number of worker processes. The default means that the pool can be empty. =item max => $count (default: 4) The maximum number of processes in the pool, in addition to the template process. C will never create more than this number of processes. =item max_queue => $count (default: 2) The maximum number of jobs sent to a single worker process. Worker processes that handle this number of jobs already are called "busy". Jobs that cannot be sent to a worker immediately (because all workers are busy) will be queued until a worker is available. =item min_delay => $seconds (default: 0) When a job is queued and all workers are busy, a timer is started. If the timer elapses and there are still jobs that cannot be queued to a worker, a new worker is started. This configurs the time that all workers must be busy before a new worker is started. Or, put differently, the minimum delay betwene starting new workers. The delay is zero by default, which means new workers will be started without delay. =item min_idle => $count (default: 0) The minimum number of idle workers - when they are less, more are started. The C is still respected though, and C/C and C/C are useful to dynamically adjust the pool. =item max_idle => $count (default: 1) The maximum number of idle workers. If a worker becomes idle and there are already this many idle workers, it will be stopped immediately instead of waiting for the idle timer to elapse. =item idle_time => $seconds (default: 1) When a worker has no jobs to execute it becomes idle. An idle worker that hasn't executed a job within this amount of time will be stopped, unless the other parameters say otherwise. =item on_destroy => $callback->() (default: none) When a pool object goes out of scope, it will still handle all outstanding jobs. After that, it will destroy all workers (and also the template process if it isn't referenced otherwise). =back =item Template Process The worker processes are all forked from a single template process. Ideally, all modules and all cdoe used by the worker, as well as any shared data structures should be loaded into the template process, to take advantage of data sharing via fork. You can create your own template process by creating a L object yourself and passing it as the C