http://www.perlmonks.org?node_id=928823

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.