Leostereo:

I've not tried your code, but I looked over the Parallel::ForkManager documentation and noticed one thing: Just as in the normal fork() system call, Parallel::ForkManager returns a PID (Process ID) to the parent process. P::FM uses that to tell you when you're the master/parent process vs. the child process. In the P::FM example, they use that fact to get the parent process to skip the child tasks work, which (as you'll notice) contains the $pm->finish call. Otherwise (and this is the hint!) the parent would *also* execute the $pm->finish task, and quit. (Mea culpa: you *did* have a PID check in there, I managed to miss it!)

So I'd suggest you do more like:

 . . .
     callback => {
          data => \&data,
          add  => \&start_new_cnx,
     },
 . . .

# Let the connection start up, and spawn a thread to handle it.
# Returns 1 for both parent and child task, so the connection isn't cl
+osed.
sub start_new_cnx {
   $pm->start;
   return 1;
}

sub data {
   # the same as you had it, but get rid of the $pm->start call, as it
+'s
   # already been started.  Just call $pm->finish when you want to end
   # the connection and terminate the task.
}
[download]

I've not tried this out yet, I just read the docs of both P::FM and IO::Socket::INET::Daemon, neither of which I've used (AFAIRemember).

Update: That wasn't your problem. I installed the packages and tried my suggestion of forking in the add callback, and had no better luck than you did. I'll try playing with it a little more and see if I can get it going.

Update 2: OK, I'm not going to mess around with this any further. I suspected that BrowserUk probably had something multithreaded with sockets somewhere around here, and found this thread in which BrowserUk assists Random_Walk getting a similar program going. You may want to review that thread and/or search for other BrowserUk threading-related threads.

...roboticus

When your only tool is a hammer, all problems look like your thumb.