NAME
Parallel::Fork::BossWorker - Perl extension for easiliy creating forking queue processing applications.
SYNOPSIS
The minimal usage of Parallel::Fork::BossWorker requires you supply the work_handler argument which returns a hash reference.
use Parallel::Fork::BossWorker;
# Create new BossWorker instance
my $bw = Parallel::Fork::BossWorker->new(
work_handler => sub {
my $work = shift;
... do work here ...
return {};
}
);
$bw->add_work({key=>"value"});
$bw->process();
Additionally, you could specify the result_handler argument, which is passed the hash reference returned from your work_handler.
use Parallel::Fork::BossWorker;
# Create new BossWorker instance
my $bw = Parallel::Fork::BossWorker->new(
work_handler => sub {
my $work = shift;
... do work here ...
return {result => "Looks good"};
},
result_handler => sub {
my $result = shift;
print "$result->{result}\n";
}
);
DESCRIPTION
Parallel::Fork::BossWorker makes creating multiprocess applications easy.
The module is designed to work in a queue style of setup; with the worker processes requesting 'work' from the boss process. The boss process transparently serializes and sends the work data to your work handler, to be consumed and worked. The worker process then transparently serializes and sends optional data back to the boss process to be handled in your result handler.
This process repeats until the work queue is empty.
METHODS
new(...)
Creates and returns a new Parallel::Fork::BossWorker object.
my $bw = Parallel::Fork::BossWorker->new(work_handler => \&routine)
Parallel::Fork::BossWorker has options which allow you to customize how exactly the queue is handled and what is done with the data.
work_handler => \&routine
The work_handler argument is required, the sub is called with it's first and only argument being one of the values in the work queue. Each worker calls this sub each time it receives work from the boss process. The handler may trap $SIG{ALRM}, which may be called if global_timeout is specified.
The work_handler should clean up after itself, as the workers may call the work_handler more than once.
result_handler => \&routine
The result_handler argument is optional, the sub is called with it's first and only argument being the return value of work_handler. The boss process calls this sub each time a worker returns data. This subroutine is not affected by the value of global_timeout.
global_timeout => $seconds
By default, a handler can execute forever. If global_timeout is specified, an alarm is setup to terminate the work_handler so processing can continue.
worker_count => $count
By default, 10 workers are started to process the data queue. Specifying worker_count can scale the worker count to any number of workers you wish.
Take care though, as too many workers can adversely impact performance, though the optimal number of workers will depend on what your handlers do.
msg_delimiter => $delimiter
Sending messages to and from the child processes is accomplished using Data::Dumper. When transmitting data, a delimiter must be used to identify the breaks in messages. By default, this delimiter is "\0\0\0", this delimiter may not appear in your data.
add_work(\%work)
Adds work to the instance's queue.
$bw->add_work({data => "my data"});
process()
Forks off the child processes and begins processing data.
$bw->process();
REQUIREMENTS
This module depends on the following modules:
Carp
Data::Dumper
IO::Handle
IO::Select
BUGS
If we knew about any bugs, we would have fixed them. :)
SEE ALSO
AUTHOR
Jeff Rodriguez, <jeff@jeffrodriguez.com>
Tim Wilde, <twilde@cpan.org>
COPYRIGHT AND LICENSE
Copyright (c) 2007, Jeff Rodriguez
Portions Copyright (c) 2011, Tim Wilde
All rights reserved.
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.8 or, at your option, any later version of Perl 5 you may have available.
1 POD Error
The following errors were encountered while parsing the POD:
- Around line 354:
You forgot a '=back' before '=head2'