Provide two C functions, say() and sayf(), and have them forward the strings on to your hook. No need to force say() to use Perl's built-in print so it can find STDOUT tied and call the tie code to eventually get the data to your code.

Also, I'm not sure why you think the process boundaries need to be divided up the way you envision. I'd just have one very simple separate process that just does the screen updates. Keep everything else together like you already have it.

I would have thought that the "GUI" part of your creation would have already forced threads much more than this little "redirect output" thing.

Most GUIs have a widget or such that will update with text when it becomes available. So imagine just redirecting STDOUT to the 'in' side of a pipe and telling such a widget to display whatever text comes from the 'out' side of the pipe.

That might not work by itself because a pipe will only buffer up a fairly small amount before trying to write more will block waiting for some of the buffered data to be read. And your widget might not get access to the CPU until the 'write' finishes. That is, deadlock.

But a responsive GUI app needs to deal with this type of thing anyway so just the "pipe to yourself" might work. But if it doesn't, all you need to add is a buffering bit pump process.

Or, simplest of all, just direct STDOUT to a temporary file and have the widget monitor the file for new text.