Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

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

by ttlgreen (Sexton)
on Feb 05, 2009 at 23:40 UTC ( [id://741741]=note: print w/replies, xml ) Need Help??


in reply to Re: Gtk2 app -- what's better, threads, or multiple timeouts?
in thread Gtk2 app -- what's better, threads, or multiple timeouts?

I had to read that a few times but I think I get it. Do you mean Pre-emptive multitasking (threads) does NOT suffer these problems.?

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.

I sure wish there was a document somewhere that explained all these concepts. This is really my first attempt at any real event-driven application. I think I'm beginning to understand though.

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

Replies are listed 'Best First'.
Re^3: Gtk2 app -- what's better, threads, or multiple timeouts?
by BrowserUk (Patriarch) on Feb 06, 2009 at 01:20 UTC
    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.
      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!

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://741741]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2024-04-18 00:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found