Re: Re: Re: Re: Pipe, fork, exec and red-hot pokers.

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.

Comment on Re: Re: Re: Re: Pipe, fork, exec and red-hot pokers.

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Pipe, fork, exec and red-hot pokers. by rob_au (Abbot) on Apr 09, 2002 at 02:45 UTC
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.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: Re: Re: Re: Pipe, fork, exec and red-hot pokers.
by rob_au (Abbot) on Apr 09, 2002 at 02:45 UTC

waitpid

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.

[reply]
[d/l]
[select]