For instance:

my @long_list_of_items;

# do not call this directly
sub main_process {
  if (@long_list_of_items) {
    process_item(shift @long_list_of_items);
    $button->after(50,\&main_process);
  }
}

# call this to add items to the list
sub add_item {
  my $schedule = !@long_list_of_items;
  push @long_list_of_items,@_;
  if ($schedule) {
    $button->after(50,\&main_process);
  }
}
[download]

Term::ReadLine::Gnu uses another trick, it calls the Tk event handler DoOneEvent() directly - with due care, because it blocks if there's no event dispatched. If the above techniques (or just the use of POE) aren't feasible, you could use that trick.

See Tk::Event.

update:

The proffered solution... Clock that goes backwards enhanced with a CPU-intensive, long running task. While the task is as silly as the clock itself, it is suitable for the POC.

It's just a matter of adding a signal handler and calling the event dispatcher in a non-blocking way.

#!/usr/bin/perl

use strict;
use Time::HiRes qw(ualarm);
use Tk;
BEGIN {*Tk::Clock::time = sub { time * -1 } }
use Tk::Clock;
my $wm = MainWindow->new;
my $ck = $wm->Clock->pack(-side => 'top');
my $b  = $wm->Button(-text => 'Start Process', -command => \&mainproce
+ss)->pack;
$ck->config(dateFormat => "dd-mm-yyy");

MainLoop;

#
# simulate a long running, CPU-intensive task
#
sub mainprocess {

    local $SIG{ALRM} = sub {
        DoOneEvent(Tk::Event::DONT_WAIT);
        ualarm(1000);
    }
    ualarm(1000);

    # task body begin

    my $c;
    $b->configure(-text => 'running...');
    while (1) {
        $c++; 
        print $c,"\n" unless $c % 1000;
        last if $c == 10000000;
    }
    $b->configure(-text => 'Start Process');

    # task body end

    ualarm(0);
}
[download]

Pretty few lines of code added... well, I could shoehorn the alarm handler into one line, and it would be 3 lines - not counting the 'use Time::HiRes' line ;-)

I guess it's not necessary to offer a code conversion job for something that simple.

_($_=" "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}

Whilst the default is to not share data between threads variables can be declared as shared, see Threads and Data for examples.

Forget what most of the people in this thread have said. Half of them have never used threads, and the other half have never tried their proffered solution in conjunction with Tk.

Take it from someone who has used threads in conjunction with tk. For the scenario you describe, using a thread is by far the simplest solution. Indeed, if you will post (or email to me) the code for your current solution that locks the gui when the "mainprocess" runs, I will convert it to use threads and prevent that, with 3* lines of code.

Let's see any of them offer to convert your existing code to their proffered solution?

*It may take a few more lines to ensure that you can interrupt the main process, or terminate it early, cleanly, but in most cases, only a few more.

You are going to show us how you do this, right? Please? A small sample program? Dave

Sure:

Existing script:

...
use threads;                   ## Additional line 1

...
async{                         ## Additional line 2
## existing, long running, cpu intensive code here
};                             ## Additional line 3
...
[download]

Now the gui will be responsive, whilst the long running code runs full speed without changes.

---

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

My what big muscles you have :D

Threads aren't about muscles. They're levers.

---

Perl Contrarian & SQL fanboy

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?

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
[download]

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

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

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}