This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54
- From: Lord Laraby <lord dot laraby at gmail dot com>
- To: Cygwin Mailing List <cygwin at cygwin dot com>
- Date: Fri, 17 Jan 2014 18:25:43 -0500
- Subject: Re: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54
- Authentication-results: sourceware.org; auth=none
- References: <831845 dot 98759 dot bm at smtp116 dot sbc dot mail dot ne1 dot yahoo dot com> <52D55D96 dot 8070407 at redhat dot com> <946338 dot 89157 dot bm at smtp116 dot sbc dot mail dot ne1 dot yahoo dot com> <52D98E1D dot 8010907 at redhat dot com> <52D9A589 dot 2050102 at redhat dot com>
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