Beefy Boxes and Bandwidth Generously Provided by pair Networks Bob
laziness, impatience, and hubris
 
PerlMonks  

Alternatives to threads for maintaining GUI app responsiveness

by metaperl (Curate)
on Sep 30, 2011 at 14:24 UTC ( #928823=perlquestion: print w/ replies, xml ) Need Help??
metaperl has asked for the wisdom of the Perl Monks concerning the following question:

We have an application running on Perl/gtk and it uses threads and threads::shared. Last night in the Freenode Perl IRC channel I learned that threads are not the best way to do 'threaded' programming in Perl.

why did we use threads?

Our single-threaded GUI app was freezing whenver we did dateabase reads and it looked like the app had crashed. Therefore we threaded the app and visual response significantly improved.

What alternatives are there to our problem

Glib already has threads

Khisanth pointed out that Glib (something used in Gtk2) has threads, so perhaps we should have been using those?

POE, AnyEvent, IO::Async

mst mentioned these as viable alternatives to threads. However, I could not persuade him to compare/contrast threads with these solutions for pros/cons.

perl threads are nearly forks anyway

From what I can see Perl threads make a copy of everything in the parent thread unless it is marked as shared.

How to achieve our goals

We mainly want our GUI app to remain responsive during background tasks and so we have a homegrown version of Thread::Queue (not my choice) which we use to queue and dequeue our data(base)? processing without tying up the mainloop of our gtk app. What other solutions exists for this problem and what are the pros/cons of this solution compared to Perl threads.

Comment on Alternatives to threads for maintaining GUI app responsiveness
Re: Alternatives to threads for maintaining GUI app responsiveness
by BrowserUk (Pope) on Sep 30, 2011 at 14:32 UTC

    why did we use threads?

    Our single-threaded GUI app was freezing whenver we did dateabase reads and it looked like the app had crashed. Therefore we threaded the app and visual response significantly improved.

    What alternatives are there to our problem

    You had a problem, you solved it. Why are you looking for alternatives?


    (Ps. Why, uniquely do you feel the need to ask your questions in

    Big Bold Lettering?

    Are they somehow more important than other peoples questions?)

      Our single-threaded GUI app was freezing whenver we did dateabase reads and it looked like the app had crashed. Therefore we threaded the app and visual response significantly improved.

      What alternatives are there to our problem

      You had a problem, you solved it. Why are you looking for alternatives?
      Because I like to know the pros and cons of possible solutions. Especially considering the fact that mst said perl threads sucked. Now, he did refuse to explain why, but he did mention those other CPAN modules as alternatives. And I also made it clear that my solution was potentially redundant/conflicting becuase Glib already had threads
      (Ps. Why, uniquely do you feel the need to ask your questions in Big Bold Lettering? Are they somehow more important than other peoples questions?)
      Each of us is a fingerprint of God, dont superimpose your fingerprint and its tendencies on mine.... or even waste your time in criticism. But anyway, I like to take the semantic aspects of my posts and use the visual layout to distinguish them.
        I like to know the pros and cons of possible solutions.

        Threads are built-in, simple, portable and are working for you now.

        The rest are non-portable add-ons, with huge learning curves, that produce complicated, hard to maintain code.

        And they don't have a solution to fundamentally blocking apis like DBI.

        Your question might make some sense if you had specific problems with the threaded solution, but it seems you are allowing the validity of your working code to be questioned on the basis of its 'coolness' with a particular group of people, who "don't like threads" but can't explain why. That's not good reasoning.


        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.
Re: Alternatives to threads for maintaining GUI app responsiveness
by zentara (Archbishop) on Sep 30, 2011 at 15:22 UTC
    Last night in the Freenode Perl IRC channel I learned that threads are not the best way to do 'threaded' programming in Perl.

    Why do you believe that? Why didn't you ask them what your alternative is? You can fork things off and pipe the results back to the parent. That is the way it was done in the old days. Threads were created to avoid that hassle.


    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku ................... flash japh
        Yeah sorry, I was temporarily stunned by the big lettering. :-) The answer is that you can't make 1 simple recipe that is best for all applications, even though everyone wants that silver bullet type of code. Its easy on the brain to have boilerplate code that is general purpose... you don't have to think as much.

        Sometimes forking is better, sometimes threads, sometimes just an event-loop is best. My rule of thumb is that if your app needs REALTIME communication between separate worker subs, use threads. If one worker dosn't care about what the other is doing, use a fork. Threads should be avoided when they are required to load big data sets, as the memory used will not be freed by the Perl process.... forking off memory hungry workers is best, as the OS will reclaim that memory when the forked process dies.

        Those are general guidlines.


        I'm not really a human, but I play one on earth.
        Old Perl Programmer Haiku ................... flash japh
Re: Alternatives to threads for maintaining GUI app responsiveness
by metaperl (Curate) on Oct 01, 2011 at 01:11 UTC
      I got some good answers in the perl-gtk IRC channel.

      No you didn't. As you'll find out when you stick your DBI query in your idle handler and your GUI freezes again.

      The most important part of that response was "don't do anything that takes more than a few microseconds".


      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://928823]
Approved by keszler
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (13)
As of 2014-04-16 12:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (425 votes), past polls