G'day simonz,

Welcome to the monastery.

That's actually a rather vague question; however, the mechanism you're probably looking for is the callback (see Tk::callbacks).

A Tk application is event-driven. You don't write code that waits for some event to occur (or complete), you associate a callback with the event which is called when that event occurs (or completes). Here's some examples:

• Don't wait for entries to appear in a log file (e.g. "while (<$log_fh>) {...}"). Associate a Tk::fileevent callback with the event of the log file having data to read (e.g. "$mw->fileevent($log_fh, 'readable', $callback)").
• Don't use a sleep statement to delay doing something until the sleep completes (e.g. "sleep $secs; do {...}"). Associate a Tk::after callback with the completion of the delay (e.g. "$mw->after($millisecs, $callback)").
• You can use Tk::bind to associate callbacks with all sorts of keyboard, mouse and GUI activities.
• The -command option of Tk::Button (and similar widgets) takes a callback as its value.

If the processing involved with a callback takes an inordinate amount of time to complete, then you may need a separate process so that the Tk process doesn't block. That could involve threads or forking a child process (see perlipc). Here's a fairly straightforward way of forking a long running process, using open and Tk::fileevent, that won't block while waiting for the child process to return output:

open my $pipe, '-|', 'long_running_process.pl';
$mw->fileevent($pipe, 'readable', $callback);
[download]

As I said at the start, your question is rather vague. The information I've provided here should be sufficient for dealing with the usual culprits. If you're having difficulty with a particular problem that I haven't addressed, post specific information and we can look at it. If you do need to post a follow-up question, please follow the guidelines in "How do I post a question effectively?": a better question gets better answers.