in reply to Alternatives to threads for maintaining GUI app responsiveness

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?)

  • Comment on Re: Alternatives to threads for maintaining GUI app responsiveness

Replies are listed 'Best First'.
threads and their alternatives
by metaperl (Curate) on Sep 30, 2011 at 15:27 UTC
    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.
[reply]
      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.
[reply]

        As an aside, AnyEvent is fairly portable and has a solution to blocking APIs like DBI. Whether that solution is really a good solution stands to debate - it spawns an external process which executes the fetch and then passes the results back via IPC. In principle, this idea isn't all bad, except that I wouldn't use one external process per query but a separate thread that does all database interaction.

[reply]
        with huge learning curves, that produce complicated, hard to maintain code.

        Can't agree with this statement, I had to work with some projects with POE and AnyEvent and it wasn't especially hard to learn and maintain. On the other hand I will not call threads simple, as most people (I'm judging by code I had to work with) either had no idea that they need to lock shared variable before accessing it at all, or are not able to implement it properly.

[reply]

In Section Seekers of Perl Wisdom