in reply to Re: Do I need threading for my GUI?
in thread Do I need threading for my GUI?

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?

Replies are listed 'Best First'.
Re^3: Do I need threading for my GUI?
by BrowserUk (Patriarch) on Feb 19, 2008 at 00:16 UTC

    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.
Re^3: Do I need threading for my GUI?
by zentara (Cardinal) on Feb 19, 2008 at 14:47 UTC
    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.

    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
Re^3: Do I need threading for my GUI?
by shmem (Chancellor) on Feb 19, 2008 at 10:00 UTC
    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}
      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.
        Because that is the logical equivalent of your advice!

        No. A construed analogy is not a logical equivalent.

        My advice is to go with the framework, and try to use features of the framework rather than bending it, or mix in stuff which might lead to problems.

        It just so happens that Tk can be used together with threads, but it wasn't written using threads - has it even been designed with threads in mind?

        The OP was about a Tk problem, so I have posted a solution which works making use of Tk and its features. It was not me who was reaching for something entirely different, but you!

        My solution might induce the wish to get a deeper understanding of how Tk works, and how to use it's lesser known internals directly - your solution of using threads just avoids a black spot which isn't in the toolkit, but in the knowledge of its user, and places on him the intellectual weight of understanding how's that thread stuff works and how to avoid pitfalls combining both... I remember you wrote something along that lines in a fine post elsewhere... ;-)

        --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}