Do you mean

Yes. Now corrected. Sorry.

So basically I could mess around trying to tune all the loops to happily co-exist and do it all again when anything changes, or just use threads because this is what they are intended for.

Ostensibly yes. As always, reality is usually a bit more complicated. Because many GUI toolkits are designed to be used as single threaded, cooperative, event-driven state machines, there is no provision within the toolkit for adding events to their event queues from other threads. Which makes adding stuff (results) to the gui from other threads a tad more awkward than you would like it to be. The solution is to use a hybrid architecture whereby the threads post results and updates for the gui to a Thread::Queue, and you use a timer in the gui to regularly check (poll) that queue from the main (gui) thread looking for thos updates.

I never did get GTK2 to work with perl on my (win32) system (though it runs fine here from Ocaml), so I cannot offer you a sample, but I'm fairly sure that zentara has posted some GTK2 + threads snippets, and we've both posted Tk samples that demonstrate the techiques.