fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54

[Lord Laraby]

Well, that is some interesting stuff. So, in POSIX, the child gets the
same FD in the same place and it is actually a second reference to the
kernels open file table. The same entry as the parent uses (via FD) to
determine the offset, flags, etc.
That would explain why the child calling exit() flushes the parents
input file as well as its own. They are the same file as far as the
kernel maintains it. As well, the buffering on the file determines how
much of the file the parent loses when the child flushes the buffer.
For a standard 4K buffer, if the input file is less than a full
buffer, the parent would see an EOF even though it had last read one
or more short lines of input. Now, if the input file had been
unbuffered at the kernel level, this would not cause the problem we
see. Perhaps we'd lose the next character read and buffered.
I must remember to call _exit() when I use fork.
The above makes sense when you consider stdout and stderr, for they
keep the parent and child from clobbering each other's output. I'm not
so sure it's useful on input files so much, though. JMHO.

LL

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple