[email]beyoderisxinc.com[/email] (Brian Yoder) writes:
As it should. After all, the only way fprintf() can now that all> All calls to fprintf() continue to return a positive value
> that indicates the number of bytes in the string I am
> sending to the client. It appears to happily buffer data in
> the pipe even though the other end is closed.
is not well is by performing the write(), but then it would loose
the performance advantage of buffering.
Did you block SIGPIPE? In my test case, the parent dies with SIGPIPE> But a call to fflush() to flush the potentially buffered
> data hangs.
after about 160 characters have been written to the pipe (over 20
separate fprintf()s). If I make it catch or ignore SIGPIPE, fprintf
eventually returns -1. I did not observe fflush() hang under any
conditions. All on AIX4.3.3
Surely you are not calling fprintf()/fflush() on a socket?> When the same scenario happens over a socket and the reader
> exits unexpectedly, the writer's calls to fprintf() and fflush()
> fail as expected and return -1 to indicate that failure.
On fdopen()ed file stream perhaps? In which case, I expect the
exact same behaviour (the one that I observed).
Construct a simple test case which tes the behaviour.
If it does, submit bug report to IBM (but chances are you'll find
a bug in your program before you get your test case to te
In order to understand recursion you must first understand recursion.