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)
(7 threads were created in this example.)
| [reply] [d/l] |
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'};
}
}
| [reply] [d/l] |
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] |