But I believe I am doing exactly that.

Imagine, for a moment the following scenario. I pinched your code above, which makes a simple way to control things. Other things - a black box. So I can send commands to your threaded example above (or something similar to it), like this:

  http://localhost:7070/startjobs

  http://localhost:7070/canceljobs
[download]

Now, in my application, the black box controlled by your threaded server example, are jobs started and canceled (worker threads managed by Thread::Pool::Simple). They are different threads than the threads that are implementing the IO::Socket::INET -based command server. (Different in that they are doing different things; pooled worker threads, versus the threads used in the IO::Socket::INET command server itself. Ultimately they are all threads.)

Hmmm, I wonder if that is more clear than before?

1. My example doesn't use a pool of threads. It starts a new thread for each connecting client.

   For low levels of concurrency and long-lived connections this is more reliable.

2. It's about 50 lines of code with no need for the 300 lines of T::P::S, or the unnecessary 60 lines of T::S or Storable.

   With complexity comes bugs.

But ultimately, it's your code, and if it's working for you and achieves the performance you require, that's great. Good luck.

---

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

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

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

"I'd rather go naked than blow up my ass"

Follow up: All your comments were right on. I ended up ditching Thread::Pool::Simple for your even more simple pool of threads approach found here: http://www.perlmonks.org/?node_id=735931