+3  A: 

The child should probably fflush() its output, and/or terminate lines properly. Otherwise the I/O buffering can hang on to the data for quite a while.

You can try to set the O_NONBLOCK flag (using fcntl()) on the child's output file descriptor before handing over control, but that will require you to change your parent code's accordingly. As pointed out in comments though, this won't help you overcome the buffering done at the C standard library level if the child uses FILE-based I/O.

unwind
Hmmm, you are right. When I fflush the output, it works. The problem is, I have no way of controlling the child. I can only control it with my test program as I can edit the source code... How do I make sure any program that is execvp'ed has its output flushed or non-buffered or something... arghhh
BobTurbo
Wait, here is the test child's code:printf("Enter input: \n"); fflush(stdout);if I take out the /n or the fflush, it delays.. I need it to read it without having a /n and.. without me fflushing.
BobTurbo
I probably shouldn't be using fgets... but not sure that solves the fflushing bit.
BobTurbo
The problem is entirely on the child's side. If the child is using line-buffered IO and is writing without newlines or `fflush()`, then the data is never leaving the child process - no-one else can do anything about that.
caf
@caf: But the child's file descriptor is created by the parent, so options can be set on it before the child get control.
unwind
If in your actual setup (where you don't have the writing program's code) you are still piping, forking, and duping to set up the child's standard output you could play around with changing settings for its output file ( O_NONBLOCK, O_SYNC, ...) with fcntl before calling an exe statement, but it's likely that the buffering is entirely within the stdio FILE buffer and not getting to the OS until it buffers are flushed on exit. You could try using a psudoterminal rather than a pipe so that stdio would think that line buffering rather than block buffering should be used.
nategoose
@unwind: It's not file descriptor options that are the problem - it's the behaviour of the stdio library in the child.
caf
@caf: D'oh! True, of course. If the client had been using raw unbuffered I/O, then it would have mattered.
unwind