Did you get an answer that you like?

A non-blocking read would work, but the need to spread checks throughout the code to test for user input is a pain.

Using signals is a possibility, but from what I've read, the problems associated with signals in perl, even on fully complient POSIX systems, mean that getting this right can be a hit and miss affair even using 5.8's safe signals.

If your target is Win32, and you don't need portability, then there is a way that might work. The idea is that you would start a thread to monitor the keyboard waiting for the user to indicate they want to interact. Your main script would be running on another thread. When you recieve user input, you can use a couple of Win32 native apis; SuspendThread & ResumeThread to pause and restart the thread running the main code whilst you make your changes. This would neatly avoid the need to litter tests throughout the main code, but is obviously very OS specific.

The only real problem I see in implementing this is that that the API's require a native 'thread handle' rather than the perl 'thread id'. This is stored and used internally by the threads module, but not exposed. It would require a small modification to the module to gain access to this, perhaps if the $thread->tid method is called in a list context, then it would return both.

I'd be willing to take a crack at making this work if anyone would find it useful. It would probably need to be based around 5.8.1 as this is the first version in which threads have begun to act in a resonably sane manner. (Just ripe for me to come along and screw them up:)