Re^3: Gtk2 app -- what's better, threads, or multiple timeouts?

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.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re^3: Gtk2 app -- what's better, threads, or multiple timeouts?

Replies are listed 'Best First'.
Re^4: Gtk2 app -- what's better, threads, or multiple timeouts? by ttlgreen (Sexton) on Feb 06, 2009 at 04:43 UTC
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 those updates. Sounds good enough, I'll have to check that out. I might be able to manage just having the (non gui-related) dirty work done in threads but I'll have to play around. 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. Great! I'll see if I can locate some of those. I assume you mean those are here in the monastary... Thanks for the help!	[reply]

Replies are listed 'Best First'.

Re^4: Gtk2 app -- what's better, threads, or multiple timeouts?
by ttlgreen (Sexton) on Feb 06, 2009 at 04:43 UTC

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 those updates.

Sounds good enough, I'll have to check that out. I might be able to manage just having the (non gui-related) dirty work done in threads but I'll have to play around.

Great! I'll see if I can locate some of those. I assume you mean those are here in the monastary...

Thanks for the help!

[reply]