Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

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

by BrowserUk (Patriarch)
on Feb 05, 2009 at 23:26 UTC ( #741733=note: print w/replies, xml ) Need Help??


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

I've noticed the gui seems to lag while the timeout functions are running.

That's the problem with cooperative multitasking (event loops).

You have to balance the needs of being responsive to interactive routines and getting work done in cpu intensive routines. Manually. By either breaking the cpu intensive bit up into iddy biddy chunks or interspersing your loops with yeilds. And just when you get the balance right on your machine, you'll have to re-tune it to run on a faster machine, or a slower machine. Or both.

And just when you think you've got that cracked, someone will call for the addition of another background task and you'll have to do the balancing act all over again. And when you've cracked that and the code goes into the field, although the users are running teh same hardware as you, they are also running another cpu-intensive program concurrently that saps half of the available cycles. That means your carefully partitioned loops now take twice as long as they do on your machine and once again, the gui becomes sluggish.

Pre-emptive multitasking (threads) does not suffer these problems. Whatever hardware you run it on, and whatever the current cpu load, except for in extreme circumstances, the OS scheduler will ensure that your gui gets sufficient and timely slices of the cpu to remain responsive. That's why threads were invented.


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.
  • Comment on Re: Gtk2 app -- what's better, threads, or multiple timeouts?

Replies are listed 'Best First'.
Re^2: Gtk2 app -- what's better, threads, or multiple timeouts?
by ttlgreen (Sexton) on Feb 05, 2009 at 23:40 UTC
    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.

      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://741733]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (3)
As of 2022-01-26 09:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:












    Results (69 votes). Check out past polls.

    Notices?