So I posted an example I had, which used a lib that you don't like, and clearly said you may not need the Glib stuff, the secret is to put the STDIN watcher in a thread. I figured a poster that asked a question like that could understand the value of reading a single key from STDIN in a non-blocking manner.

But instead of accepting that as 1 way to solve the STDIN problem( and is a preferred way on linux, to avoid select and multiple select timeouts), you chose to jump on the Glib module, for some reason, possibly because you don't like it. Probably because it was not designed for Win32 exclusively, which you seem to prefer. Or maybe you don't understand the concept that a snippet may be posted to demonstrate a principle, but not give an exact answer. The Term::Readkey was invoked to read a single key, rather than line input, and was mentioned by the OP, so it is fair to include. Thread::Queue ?? I can't stand that module, but do I respond to your posts advocating it's use as waste and source of problems?

You said: And if you need to do something that'l take a few seconds, your going to have to break it up into iddy biddy chunks, or lace it through with some do_one_event() call or similar.

Clearly you havn't read the docs for the Glib module, Idle->add() will add anything you want into the loop one time, you don't need a timer for everything.

You said:Rubbish! As soon as you enter that MainLoop-run, your main "thread" is dead until something signals stop.

For as smart as you seem to be in your other answers, you show a complete ignorance of eventloop systems. Maybe you are just having a bad day. My guess is that you are stuck on win32, and don't want to expand your horizons, like most MSjunkies.

You said: Oh! And what Win32 modules would that be?

Win32::SocketPair