Perl/Tk and threads on Win32

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

Esteemed monks,

It seems to have been repeated often here and elsewhere that the current Tk implementation is not thread safe and that the threads implementation is not really friendly with Tk, at least on Win32. Yet in Perl/Tk App and Interprocess Communication which is referred to this morning in Tk GUI and Listen? we have a suggestion to use threads in Win32 with Tk.

Just how safe is this?
Are there any simple tricks that facilitate the use of threads with Tk in Win32?

jdtoronto

Comment on Perl/Tk and threads on Win32 Download Code

Replies are listed 'Best First'.
Re: Perl/Tk and threads on Win32 by ldln (Pilgrim) on Oct 27, 2006 at 18:08 UTC
My 2cents (before the experts come along) is that it works well. The thing, in addition to starting any threads before doing any work with Tk, is to start the threads as early as possible with "use" (compile time) and then "require" (runtime) as much as possible of the other modules needed, so that the stuff copied into the other "worker" threads is as minimal as possible. For instance by using "use Tk;" instead of "require Tk;" we clearly see that lot of extra Tk stuff is copied into the new threads by looking at mem usage in task manager. `use Tk; mem usage perl.exe: 24MB/21MB (phys/virtual) require Tk; mem usage perl.exe: 12MB/9MB (phys/virtual)` [download] (7 threads were created in this example.)	[reply] [d/l]
Re: Perl/Tk and threads on Win32 by zentara (Archbishop) on Oct 27, 2006 at 18:15 UTC
I have limited experience with Win32, but with the limited tests that I've done, they work as well as on linux. I did run into a glitch with the way the various win32 versions handle shared variables. For instance, ME and earlier can't handle deep hashes, but XP handled it fine. So I would be cautious about thinking that anything that runs on XP will work with earlier releases. my @chs = (1..99); # setting this to 2 works on windowsME # but will bog down over 3, and crash # at values like 60 my $max_prog_chan = 60; my %days; foreach my $channel(@chs){ foreach my $count(0..$max_prog_chan){ #print "$channel $count\n"; share $days{$channel}{$count}{'channel'}; share $days{$channel}{$count}{'channel_info'}; share $days{$channel}{$count}{'episode_num'}; share $days{$channel}{$count}{'start'}; share $days{$channel}{$count}{'stop'}; share $days{$channel}{$count}{'makedate'}; share $days{$channel}{$count}{'description'}; share $days{$channel}{$count}{'title'}; share $days{$channel}{$count}{'writer'}; share $days{$channel}{$count}{'director'}; share $days{$channel}{$count}{'actors'}; share $days{$channel}{$count}{'rating'}; share $days{$channel}{$count}{'length'}; share $days{$channel}{$count}{'category'}; share $days{$channel}{$count}{'star_rating'}; } } [download] I'm not really a human, but I play one on earth. Cogito ergo sum a bum	[reply] [d/l]
Re^2: Perl/Tk and threads on Win32 by Anonymous Monk on Oct 28, 2006 at 21:24 UTC
The points made above are good. In addition I believe tk has issues with threads because it maintains its own state seperate to that of perl, so if you have tk objects accessed by multiple perl threads it will fall to pieces. To avoid these problems, spawn multiple threads early on, and create/interface with tk from your main thread/one thread only. Pass information or actions from your gui/tk thread to your worker threads via shared variables / thread safe queues or IPC etc. One possible advantage to this is that you have a better chance of ensuring your gui doesnt freeze during blocking actions as they will be passed to your worker threads. On the downside... your apps memory usage may well be huge by adding a gui - thats been my experience. Good luck, Rossco	[reply]

Back to Seekers of Perl Wisdom