I'm relieved you left out Glib :-)

Drat! Knew I was forgetting something :)

It seems that people want to find general solutions for all problems of a certain type, then set that problem aside as being solved,

I understand the motivation, but often I see "them" creating themselves far more work than they save, by doing so.

Some problems lend themselves to a particular approach naturally. For example, GUIs require an event loop--nothing else will do. The problem arises when the fact that a particular application needs a GUI is used to determine that everything else that application does, has to be force-fitted into an event-driven architecture. It simply doesn't need to be that way.

You know yourself--as you've done it here many times--that it is perfectly good and proper to set the GUI event loop running in a thread--main or otherwise--and push other, naturally serial proceses--like read-process-write loops, off into background threads. Sure, there are issues that most of the available GUI libraries were never written to work across threads, but as you know, there are simple solutions to those problems.

There are other things that naturally lend themselves to event-driven architectures. Eg. Starting a whole thread to ping each of a long list of machines doesn't make sense. Sure, you can avoid that by using a thread pools and a queue, but it still probably isn't the best mechanism. Which is why when that question comes up, I suggest the asynchronous capabilities of Net::Ping.

The really nice thing about that module, is that it happily runs in a thread. So, if the application wants to display the running status of the network in a gui, it is very easy to separate and test those two aspects of the application. You stick the gui in one thread, the network discovery in another and communicate the status between them using a queue.

In this way, both parts of the application can be developed and tested separately, and you avoid having to try and interleave their processing in a way that means you are always having to trade the requirements of one, for those of the other.

Similarly, in a spidering application, LWP::Parallel can be used to great advantage in conjunction with threads. If you try to use just threads, you need to start many threads per core to ensure that each core always has something to do. If you try to use just an event loop architecture, you don't scale across cores and so waste 3/4; 15/16th; 255/256ths etc. of your available processing power. Start one or two threads per core and run an event loop (LWP::Parallel) instance in each, and you get the best of both worlds.

And that's my 'problem' with 'frameworks'(*). By inverting the flow of control, they dictate the architecture of every application that uses them. They force the conflation of what should be separate concerns. By precluding other constructs and methodologies, they exclude the 'natural' solutions to simple problems and you end up with people trying to use complicated semaphoring mechanisms to re-create simple, linear-flow, serial processing. Or polling every 1/10 second to check on the progress of stuff that may takes hours--and that they don't really care how long it takes, they just need to do something when it is done.

I love chips. But the idea of fried spagetti or fried strawberries fills me with horror. I like mashed potato; but boiled fish or steak?

(*)Not all frameworks are bad. From my limited understanding of CGI work, you pretty much need a framework to do anything remotely complex with the stateless nature of http. You either use an existing framework, or are destined to create one (usually badly), in order to bring some level of statefullness to your application.