X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; q=dns; s=default; b=s9
	fZCFyYBm1iJRRHRcToJquKkcNEs+MUeUFmsx1eRHi0a7fQgthz6FahDMS439b4B4
	TIemfBahK6HqtHBzZ2noyDU8gfrY/hiOVaWBhlW+Y7yXiR9V7i/6ju5mkWb1b4qV
	hL4CZI5QyDrF6Y1zrTJLbAvBmgYemDgc6hWx1duq4=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; s=default; bh=DaakeDTO
	tg4yG4bSFkrRYikrcS8=; b=aIjsCORoU3llN4SDpZeqWwzvs+vH8AGEC2KMJc3q
	EWYgSryd+9eaw9VwbEPd03Ugcjs2Smfmse5n+5B/0T5UojFUGckNr1B/nEIBZXVQ
	jfrXDVwjYIZ34rr58N5QQcG+TJtBaiFyn3bUe5HHkZpdh02dlqsJc9Rr3qOBNDe9
	uu4=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-qa0-f52.google.com
MIME-Version: 1.0
X-Received: by 10.229.179.5 with SMTP id bo5mr8015475qcb.21.1390001143581; Fri, 17 Jan 2014 15:25:43 -0800 (PST)
In-Reply-To: <52D9A589.2050102@redhat.com>
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>
Date: Fri, 17 Jan 2014 18:25:43 -0500
Message-ID: <CAG9p0OSzOUWf=VyK+f+Q2wBYUd2yiz9uwbtQOkTMOc4arvcMXg@mail.gmail.com>
Subject: 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>
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes

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