Alternatives to threads for maintaining GUI app responsiveness

metaperl has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
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	[reply]
Re^2: Alternatives to threads for maintaining GUI app responsiveness by metaperl (Curate) on Sep 30, 2011 at 15:31 UTC
I dont know if you saw this line in my OP: mst mentioned these as viable alternatives to threads. However, I could not persuade him to compare/contrast threads with these solutions for pros/cons. The mantra of every experienced web application developer is the same: thou shalt separate business logic from display. Ironically, almost all template engines allow violation of this separation principle, which is the very impetus for HTML template engine development. -- Terence Parr, "Enforcing Strict Model View Separation in Template Engines"	[reply]
Re^3: Alternatives to threads for maintaining GUI app responsiveness by zentara (Archbishop) on Sep 30, 2011 at 17:25 UTC
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	[reply]
Re: Alternatives to threads for maintaining GUI app responsiveness by BrowserUk (Patriarch) 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?)	[reply]
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]
Re: threads and their alternatives by BrowserUk (Patriarch) on Sep 30, 2011 at 15:47 UTC
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]
Re^2: threads and their alternatives by Corion (Patriarch) on Sep 30, 2011 at 20:23 UTC
Re^3: threads and their alternatives by BrowserUk (Patriarch) on Sep 30, 2011 at 21:42 UTC
Some notes below your chosen depth have not been shown here
Re^2: threads and their alternatives by zwon (Abbot) on Oct 02, 2011 at 06:30 UTC
Re^3: threads and their alternatives by BrowserUk (Patriarch) on Oct 02, 2011 at 06:50 UTC
Some notes below your chosen depth have not been shown here
Re: Alternatives to threads for maintaining GUI app responsiveness by metaperl (Curate) on Oct 01, 2011 at 01:11 UTC
Well I got some good answers in the perl-gtk IRC channel. 11:59:09 <metaperl> i'm wondering about alternatives to threads for keeping a perl/gtk app responsive - http://perlmonks.org/index.pl?node_id=928823 12:03:31 <LotR> simple. don't do anything that takes more than a few microseconds :) and if you do, split it up in tiny pieces and stick those in an idle handler. 12:03:34 <LotR> also, see POE 12:32:49 xiong ~xiong@c-69-181-68-53.hsd1.ca.comcast.net has quit IRC: Ping timeout: 600 seconds 12:41:57 xiong ~xiong@c-69-181-68-53.hsd1.ca.comcast.net has joined #gtk-perl 12:46:31 <metaperl> i'm wondering about alternatives to threads for keeping a perl/gtk app responsive - http://perlmonks.org/index.pl?node_id=928823 12:46:43 <metaperl> oh sorry 12:46:46 <metaperl> for the repeat 12:46:52 <metaperl> My window was smushed down 12:47:20 <metaperl> lotr - what is an idle handler? is this documented somewhere? 12:49:21 <metaperl> this looks relevant - http://search.cpan.org/~rcaputo/POE-Loop-Gtk-1.305/lib/POE/Loop/Gtk.pm 13:09:56 <squentin> metaperl: Glib::Idle->add(\&my_function) see http://gtk2-perl.sourceforge.net/doc/pod/Glib/MainLoop.html The mantra of every experienced web application developer is the same: thou shalt separate business logic from display. Ironically, almost all template engines allow violation of this separation principle, which is the very impetus for HTML template engine development. -- Terence Parr, "Enforcing Strict Model View Separation in Template Engines"	[reply]
Re^2: Alternatives to threads for maintaining GUI app responsiveness by BrowserUk (Patriarch) on Oct 01, 2011 at 02:56 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.	[reply]

Alternatives to threads for maintaining GUI app responsiveness

why did we use threads?

What alternatives are there to our problem

Glib already has threads

POE, AnyEvent, IO::Async

perl threads are nearly forks anyway

How to achieve our goals

Big Bold Lettering?


Clear questions and runnable code get the best and fastest answer
	PerlMonks