See I find this to be less and less true as POE develops. For example last year I wanted to hook a POE based IRC bot up to a web service. I didn't want to figure out how to make PoCo::Client::HTTP work when I knew I could get things off the ground quickly with LWP. So I wrote it with LWP, in a straight OO fashion and then used POE::Component::Generic to handle making it non-blocking for POE.

Perhaps I have an odd case where my issue is just simple enough to work, but increasingly POE is becoming a decent solution for non-blocking code. The results are in the Net::AIML dist.

In my experience threading/forking doesn't change the issues most people are going to have, it just means you have to re-write a bunch of wheels dealing with concurrency and blocking (literally POE::Wheel's in the case of forking) instead of learning the POE API for doing the same tasks. But then I'm obviously biased toward POE which had a stable API when I started writing concurrent code, where as threading didn't.

Care to post the code?

---

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

I already did.

See CPAN

POE::Component::Generic is an interesting module that I haven't seen before, and that could help a lot of people. I don't mean to knock the quality of POE's implementation. Forking a child process every time you want to do any I/O is still quite a paradigm shift though.

Forked/threaded environments actually do completely eliminate this problem for most people, since the forking is done for them. Think CGI/FastCGI/mod_perl. You don't have to worry about killing the entire server with a thoughtless LWP call in those environments.