my $STDOUT = IO::Handle->new;
my $STDERR = IO::Handle->new;
open($STDOUT, ">&STDOUT") ||
    croak( 'Cannot duplicate STDOUT to file handle - ', $! );
open($STDERR, ">&STDERR") ||
    croak( 'Cannot duplicate STDERR to file handle - ', $! );

$STDOUT->autoflush;
$STDERR->autoflush;
[download]

If you still have no joy with this, you may have to incorporate a flush of the respective buffer prior to reading from it. eg. $STDOUT->flush. This may be necessary if some_application is actively buffering its output.

I'd be very interested to hear how you go with this and see if this resolves your problems with your specific application.

No dice ... :( Same result.

Here's my current theory. some_application believes that it's not running on a terminal (correctly), so it stops line buffering for some reason. It *does* flush its buffers on termination and on reaching the 4096 buffer limit (or whatever the precise number is).

So perhaps another avenue to persue is fooling some_application into thinking that $STDOUT is in fact a tty?

--
Ash OS durbatulk, ash OS gimbatul,
Ash OS thrakatulk, agh burzum-ishi krimpatul!
Uzg-Microsoft-ishi amal fauthut burguuli.

I've figured it out ... waitpid! *smacks own forehead*

This is causing execution to halt until the child process invoked by open3 has terminated. As such, the latter lines which read from the $STDOUT and $STDERR are not being executed until after child has terminated and thus delays between output on these handles cannot be appreciated. You will need to remove the waitpid statement if you want to read from these output streams while some_application is executed.