use Parallel::ForkManager;

 # Begin ForkManager
 my $_max_procs = 5;
 $_pm = new Parallel::ForkManager($_max_procs);

 # Log at process fork
 $_pm ->run_on_start(
   sub { my ($pid, $host) = @_;
     print "Forking process PID: $pid\n";
   }
 );

 # Log at process copmletion
 $_pm ->run_on_finish(
   sub { my ($pid, $exit_code, $func) = @_;
     print "Finishing up process PID: $pid\n";
   }
 );

 # This run_on_wait is currently set to print every 5 sec
 # It can easily be modified to write to a socket every X sec
 $_pm->run_on_wait(
   sub { print "Waiting for children to finish.\n" }, 5.0 );

foreach my $func (@func_list) {
  # Fork off the children and get going on the queries
  my $pid = $_pm->start($func) and next;

  # foo here

  # Closing the forked process
  $_pm->finish;
}

# Ensure all children have finished
$_pm->wait_all_children;
exit(1);
[download]

I am assuming that this module is available on the win32 platform since I just got it off of CPAN.

T'is easy.

#!/usr/bin/perl -w

use IO::Socket;
use strict;
use threads;
use threads::shared;

#sock is my connection where I report what is going on
my $sock = IO::Socket::INET->new(
    PeerAddr => 'hostname.org',
    PeerPort => '1234',
    Proto => 'tcp'
);

my $done:shared = 0;
my $thread = async{ long_running_function(); $done = 1 };

print $sock "I'm still here" and sleep 180 until $done;
my $return_value = $thread->join;
print $sock "$return_value\n";
close $sock;
[download]

Ultimately the answer, in some form or another, is threads. The tutorials section contains Threads: why locking is required when using shared variables and Things you need to know before programming Perl ithreads, neither of which is a tutorial that introduces the concepts you require, nor paints in the big yellow and black warning borders around the tricky areas. The Perl documentation contains perlthrtut, which may be a good start. Another way to go about things (by hiding the tread stuff under the hood somewhat) is to use POE.

Beware, threads can be tricky creatures that bite in nasty and unusual ways. On the other hand, there are a few Perl Monks around with a fair amount of experience taming them so pleas for help will certinally be answered. Good luck ;).

perlthrtut is almost completely useless as a starting point on how to use iThreads.

Things you need to know before programming Perl ithreads (which I refuse to link), describes a situation circa. v5.8.0 (the first ever iThreads build) & v5.8.1 (the buggiest threaded perl build ever, that lasted a whole 41 days before being superceded), from the perspective of someone who attempted to emulate iThreads with forks--and failed. Update: Are you going to refer newbies to Things you should need to know before using Perl regexes. (Humour, with a serious point) when they ask about regexes?

And, in the process succeeded in littering the entire cpan Thread::* and (as I recently discovered) thread::* namespaces with over-ambitious, unsupported (and almost unsupportable), mostly defunct, and do nothing modules that are in great part the cause of the difficulties that people have trying to use iThreads, (Now sadly billed as the "greatest authority on Perl threading"!).

Finally, how about you try writing a POE solution before you recommend it to others on the basis of hearsay.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.