Re: Thread::Pool shutdown dies after abort

[BrowserUk]

A simple, working solution:

#! perl -slw
use strict;
use threads;
use Thread::Queue;

$|++;

sub worker {
    my( $Q ) = @_;
    while( my $workitem = $Q->dequeue ) {
        print "Processing $workitem";
        sleep rand 10;
    }
}

our $THREADS //= 2;

my $Q = new Thread::Queue;

$SIG{'INT'} = sub{
    print "Sigint seen";
    $Q->dequeue while $Q->pending;
    $Q->enqueue( (undef) x $THREADS );
};

$Q->enqueue( <DATA> );

my @threads = map threads->new( \&worker, $Q ), 1 .. $THREADS;
$Q->enqueue( (undef) x $THREADS );
sleep 1 while $Q->pending;
$_->join for @threads;

__DATA__
WorkItem 1
WorkItem 2
WorkItem 3
WorkItem 4
WorkItem 5
WorkItem 6
WorkItem 7
WorkItem 8
WorkItem 9
WorkItem 10

[sundialsvc4]

I really like this approach, because it clearly delineates “the units of work that are to be processed” from “the pool of worker-bees that is responsible for processing them.”

There should be enough threads/processes available to allow them to process the incoming requests expediently without unreasonable backlogs ... but they should process many requests during their lifetime, pulling them from a nice, thread-safe queue.   BrowserUK's solution clearly demonstrates just how easy that is.

A fast-food restaurant uses exactly the same system to churn out hundreds of grease-burgers to five simultaneous lines in the lobby, as well as one or sometimes two drive-thru windows, using just a handful of grossly-underpaid employees.   And no workers are murdered by their manager during the entire shift.

[Anonymous Monk]

Thanks Monks for your answers. I think an approved thread pool package is needed with all the trimmings.

[BrowserUk]

I think an approved thread pool package is needed with all the trimmings.

Why? What do you need that this does not do?