Before you go down a road, it's good to look at the skeletons and gravestones by the wayside.

• AnyEvent, EV
• POE

Also, the question of what to use instead of a mainloop remains. Of course you can (try to) use threads and messaging instead of separate mainloops, but you'll find that Gtk2 (for example) doesn't play well when run in a thread that is not the main thread, and so do other "mainloop implementors".

There exist modules to combine some combinations of EV, Event and Glib: EV::Glib, Glib::EV and Glib::Event.

Also AnyEvent is a way to write event-loop neutral modules (supporting at least Tk, Glib2, POE, EV, Event, IO::Async and a pure perl event loop). This is similar to how POE::Loop works, but EV is an event-loop of its own. An ugly and hackish way of combiining multiple loops would be to single step through event loop 2's events on event loop 1's idle callback or on a timer (most event loops support processing their pending events one at a time instead of running their mainloop directly).

Update: Another possibility for adding EV loops to other event-loop using modules is EV::Loop::Async, which lets you embed an mod:://EV loop into code using a different mainloop with Async::Interrupt, which allows asynchronous interruption of running perl code with through the signal mechanism.

Or, you know, Coro if you don't want to mess with event-oriented programming. Sometimes one is easier, sometimes the other.

Rules and standards are unlikely to be helpful unless you first establish why people have been putting main loops inside of modules. If you outlaw a legitimate practice, your programmers will jump through hoops to get things done and things may end up even more of a mess than they were before.

You might benefit from consolidating main loop processing into a single "main loop management module". On the other hand, you may have some very good reasons for needing separate ways of handling the main loop portion of a program. Placing the main loop of a program in a module separate from the launch script is a well established programming practice, especially if the action of the main loop is complex and needs lots of supporting functions. Only your team (or close analysis of the code) can answer that question.

I'd also take a careful look at how your code is factored into modules. It is usually a good idea to keep main loop code in a separate module from general purpose code. People may have lots of reasons to use that super-duper-string-muncher subroutine, but if super-duper-string-muncher is sitting in a module with an event loop, only programs that need both string-muncher and that particular event loop can use it safely. Perhaps a rule that "main loops" need to be in a separate specially named module (OurCompany::MainLoop::AppNameHere for example) would solve the problem better than an arbitrary limit on the number of main loops.

Best, beth

my $app = App::SuperDuper->new;
$app->repuDrepuS;
...
$app->MainLoop;
[download]