Seems to me that the problem here is that you are trying to use tie *STDOUT, 'Tk::Text', $widget; in ways it simply wasn't designed to work.

Although a brief scan didn't turn up any docs for tieing TK widgets in this way, it seems pretty likely that it is intended to take the output from a separate process and pipe it into the tied widget. And under win32, with fork being just an emulation using a thread, and async being a thread, what you're actually trying to do is pipe what is written to STDOUT by one thread and read it back from another thread.

STDOUT is process global--ie. shared by all threads in the process, although different threads my have different cloned/duped handles to it--which means that you would (at least) need to some kind of synchronisation between the threads. But I see no way of providing that without digging deep into the guts of the Tk widget/tie mechanism, which from past experience is a distinctly non-trivial undertaking.

The idea of writing from your process, into a piece of system allocated memory from one thread and then reading back from that system allocated memory in another thread and expecting the "system" to successfully mediate that is just a tad optimistic :)

You have a couple of options,

1. Run your 'program' as a true separate process, (per ikegami's post), but using Win32::Process so that you can have the child process inherit the parent (Tk) process' standard handles.

   That might allow the tieing of STDOUT to a text widget to work?

2. Run your subroutine in a thread, but modify it to write to a Thread::Queue instead of STDOUT. Then set-up a Tk::after repeating timer to read from that queue and write to the text widget.

   This keeps all the Tk interaction firmly in a single (main) thread. It works! And there are several examples of it kicking around this site.