|
in reply to Do I need threading for my GUI?
I pretty much agree with BrowserUk, threads are simple and uncomplicated for doing your task. Tk with threads presents a bit of a roadblock, because the thread needs to be created before the Tk code is called, but it is easily done. The only thing not mentioned, is if you need feedback from/to the process as it runs. If so, threads are a good choice, BUT if you are just launching the process and letting it go off on it's own, a simple fork-and-exec may be cleaner.
|
Re^2: Do I need threading for my GUI?
by tamaguchi (Pilgrim) on Feb 18, 2008 at 23:37 UTC
|
Thank you all for your answers I did like this:
my $mythread = new Thread \&MainEntry::StartProcessing;
It looks at it was sufficient to solve the problem.
Im not sure if the thread is alive after it has finished
the StartProcessing sub however..I have tried to $mythread->detach; but it gives me a the error:
"Attempt to free non-existent shared string '_TK_RESULT_', Perl interpreter: 0x1f28444 at C:/Perl/site/lib/Tk/Widget.pm line 98 during global destruction. Free to wrong pool 1f273d8 not 223f90 at C:/Perl/site/lib/Tk/Widget.pm line 98 during global destruction. "
Does anyone have a clue what the problem might be?
| [reply]
[d/l] |
|
|
It means that one (or more) Tk variables was (unnecessarially and incorrectly) cloned from the main thread into the child thread when you spawned it. And when Perl attempts to clean it up (during global destruction), it doesn't know how. It can be safely ignored.
If you only intend to start one (or a few) threads, you can defer the error until the program terminates by not detaching the threads. You will then receive a message along the lines of:
Perl exited with active threads:
0 running and unjoined
1 finished and unjoined
0 running and detached
Which again can be safely ignored (but unfortunately not turned off).
As zentara pointed out elsewhere, it is possible to avoid these errors by starting the non-Tk threads prior to loading Tk so that the cloning doesn't happen, but unless you are intending starting enough threads for their dead corpses hanging around to become a (memory) problem, the extra complexity involved is usually not worth the effort.
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]
[d/l] |
|
|
The real question is do you want to collect output from the processing in the thread? You don't say what the rest of the Tk gui is doing, like tailing a log file, or receiving and printing results? Is the command you are running in the thread, run thru system or backticks? See PerlTk on a thread... for tips on setting up a Tk thread. If you want to delay the start of the processing, until a button is pressed, try making a sleeping thread, which wakes up on a button press, as in Tk-with-worker-threads. The thing to notice with a sleeping thread, is you create it before any Tk is called, you put it in a sleep loop, waiting for a shared variable to change, which signals it to wake up and start processing.
| [reply] |
|
|
This is probably the reason why many of us say "don't use threads for this task".
Stick with the framework. It doesn't use threads and is event based? Don't use threads, use
events, then. The problem can be solved within the same framework, without adding threads into
the mix. Starting a long running sub prevents Tk from servicing other events? Make sure your
sub cooperates and yields time slices to Tk.
I'm not saying that it is a bad idea to use Tk within a threaded application, but that it is
probably not so good an idea to use threads within Tk, since the framework itself is threads-unaware
and probably not programmed in a thread-safe way; so using threads within it requires good understanding
of the working of both perl threads and Tk.
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] |
|
|
This is probably the reason why many of us say "don't use threads for this task".
Even though you admit to having made little (no?) use of threads?
If you encountered a bug in a regex, that allowed the regex to work but causes a warning during global destruction, would you advocate the replacement of all regexes using character by character comparisons and huge if/else cascades?
Eg. You'd advocate if( $string =~ m[C\d\[A-Q]] ) { with
my $currentChar = substr( $string, $n, 1 );
if( $currentChar eq 'C' ) {
$currentChar = substr( $string, ++$n, 1 );
if( $currentChar eq '1' ) {
$currentChar = substr( $string, ++$n, 1 );
if( $currentChar eq 'A' ) {
...
...
...
...
elsif( $currentChar eq 'B'
...
...
...
...
}
elsif( $currentChar eq '2' ) {
...
...
...
...
}
elsif( $currentChar eq '3' ) {
...
...
...
...
}
elsif( $currentChar eq '4' ) {
...
...
...
...
}
elsif( $currentChar eq '5' ) {
...
...
...
...
}
elsif( $currentChar eq '6' ) {
...
...
...
...
}
elsif( $currentChar eq '7' ) {
...
...
...
...
}
elsif( $currentChar eq '8' ) {
...
...
...
...
}
elsif( $currentChar eq '9' ) {
...
...
...
...
}
else {
die "The second char was not in range '1' thru '9';
}
}
else {
die "The first character didn't match 'C'";
}
Because that is the logical equivalent of your advice!
Or might you suggest working around the problem, and report the error, in the hope that the regex engine would get fixed?
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]
[d/l]
[select] |
|
|
|
|
