Reading [id://BrowserUK]'s post Re^3: My First POE - Simple Parallel Programming, I feel that some clarifications are needed in regards with my example code:

• I've chosen the forked example, because these posts, Re: My First POE - Simple Parallel Programming and Re: My First POE - Simple Parallel Programming imply that POE is not about multithreading and forking (oh, and _yes_ POE is asynchronous)
• I mentioned that TIMTWOTDI applies to POE as well. Let me elaborate a bit on this:

• You can use the forked approach.
• You can use the single select based process model
• You can use multi-machine model, using POE::Component::IKC
• Or more

With this particular simple example, it may seem that the POE solution is bigger (in terms of amount of code written) than the threaded one. Now consider extending the application, so you need to run those functions on different machines. Here POE::Component::IKC comes in handy. I guess the threaded solution would be much bigger (again in terms of amount of code written). But I don't want to start a debate on this.

Also, the use of POE::Wheel::Run and POE::Filter::Reference makes it a piece of cake to "port" a basic forked application to POE.

Last and not least, IMO POE makes more sense for those (like me) that find it easier to think in terms of a Finite State Machine.

p.s.: I deliberately ignored the "speed" issues between the different implementations.