Hmm. About all I can say is that you are moving in uncharted waters. threads used to carry a dire warning about creating threads inside special blocks:

Creating threads inside BEGIN, CHECK or INIT blocks should not be relied upon. Depending on the Perl version and the application code, results may range from success, to (apparently harmless) warnings of leaked scalar, or all the way up to crashing of the Perl interpreter.

And, unlike some of the other overly pessimistic warnings about threads, I've personally experienced intermittant failures and traps when using threads created within BEGIN{} blocks. From memory, these occured with both 5.8.3 and 5.8.5, hence I gave up trying long ago. I don't have a handle on how things stand on later builds.

That warning has now disappeared from the latest cpan version of threads, but there's no real way to know if it was deliberately removed because the cause had been found and fixed, or if it just got omitted along the way.

Do you think it would be possible to safely create a thread that binds the glut keyboard input callbacks and then creates a second opengl main loop that processes ONLY those?

The whole area of callbacks and threads is pretty iffy. Even conceptually. What happens if the code doing the calling back is running in a different thread to that which passed in the address to be called back?

At the C-level, provided that the callback routine is reentrant and doesn't rely on thread local storage, it'll probably work ok. But in Perl, I really have no idea what would happen, but my gut feeling is that it wouldn't be good.

And the idea of running two "main loops" seems very unlikely to work.