Parallel::Fork::BossWorker - Perl extension for easiliy creating forking queue processing applications.


Parallel-Fork-BossWorker documentation  | view source Contained in the Parallel-Fork-BossWorker distribution.

Index


NAME

Top

Parallel::Fork::BossWorker - Perl extension for easiliy creating forking queue processing applications.

SYNOPSIS

Top

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 = new Parallel::Fork::BossWorker(
		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 = new Parallel::Fork::BossWorker(
		work_handler => sub {
				my $work = shift;
				... do work here ...
				return {result => "Looks good"};
			},
		result_handler => sub {
			my $result = shift;
			print "$result->{result}\n";
		}
	);

DESCRIPTION

Top

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

Top

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

Top

This module depends on the following modules:

Carp

Data::Dumper

IO::Handle

BUGS

Top

None I'm aware of yet, but I'm sure I'll receive reports :)

SEE ALSO

Top

AUTHOR

Top

Jeff Rodriguez, <jeff@jeffrodriguez.com>

COPYRIGHT AND LICENSE

Top


Parallel-Fork-BossWorker documentation  | view source Contained in the Parallel-Fork-BossWorker distribution.