X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=0.5 required=5.0	tests=AWL,BAYES_50,KHOP_THREADED,URI_HEX
X-Spam-Check-By: sourceware.org
Date: Wed, 29 Aug 2012 00:34:45 -0700 (PDT)
From: thoni56 <thomas AT junovagen DOT se>
To: cygwin AT cygwin DOT com
Message-ID: <6BCD31F5-C65C-42D7-BB5A-D899B301564C@junovagen.se>
In-Reply-To: <503C6DEB.3090101@abacus.ch>
References: <1346135219441-92349 DOT post AT n5 DOT nabble DOT com> <503C6DEB DOT 3090101 AT abacus DOT ch>
Subject: Re: fork() and file descriptors with un-flushed output
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id q7T7ZGAP007773

Thank you both! You learn something everyday. Thank you very much!

The suggestions from Daniel worked beautifully!

/Thomas




28 aug 2012 kl. 09:07 skrev "Wolf Geldmacher [via Cygwin]" <ml-node+s1069669n92353h20 AT n5 DOT nabble DOT com>:

> This is not a bug - it's a feature ;-) 
> 
> The "issue" you are describing is in fact the standard behaviour 
> expected of fork() in any unix/posix compliant implementation. 
> 
>  From the fork man page on Linux: 
> 
> > ... 
> > fork()  creates  a new process by duplicating the calling process.  The 
> >  new process, referred to as the child, is an  exact  duplicate of  the 
> >  calling  process,  referred  to as the parent, 
> > ... 
> 
> and yes, "exact duplicate" includes all data in buffers not yet flushed. 
> 
> The difference in behaviour when you  run your program from the terminal 
> vs. from Emacs stems from the "intelligence" built into the stdio 
> library that looks at type of the file a stream is connected to and 
> automagically turns on full buffering if it is not connected to a 
> terminal in order to optimize performance. 
> 
> To avoid the duplication of data you can either explicitly turn off 
> buffering with setbuf() (and pay the associated performance penalty), 
> fflush() your open files before you fork (usually the easiest to 
> implement), or revert to the use of the basic OS functions open(), 
> read(), write(), close() (useful for special cases when not much of 
> stdio is needed - make sure you don't mix the two). 
> 
> Cheers, 
> Wolf 
> 
> On 28.08.2012 08:26, thoni56 wrote:
> 
> > Maybe this is an FAQ but I could not find it in it ;-) or in the lists I 
> > searched: 
> > 
> > In cygwin, when you fork() process shares file descriptors. If there happens 
> > to be unflushed output in such a shared file descriptor buffer, would that 
> > be output by both processes? 
> > 
> > I have some empirical evidence to support this theory. I support cgreen, a C 
> > unit test and mock framework, which runs every test case in its own 
> > processes using fork(). 
> > 
> > For many years I have seen the effect that when running in a command window 
> > every thing works as expected, But running in Emacs created multiple 
> > outputs. That has not bothered me that much but know I implemented some 
> > further output routines in the reporting code, and everything just blew up! 
> > 
> > The test case is run in a separate processes using fork() which then 
> > messages back and then dies. The output from the runner (parent process) 
> > written to the file before the fork() is then output twice. 
> > 
> > This behaviour changed to the expected (only printed once) if a fflush() was 
> > added after the printf() in the parent process before the fork. I'm 
> > suspecting this happens because of unflushed output in the file buffer which 
> > is shared by the two processes, first flushed when the child dies, then 
> > flushed by the parent at some point, not only duplicating output, but also 
> > garbling it. 
> > 
> > Is this a known behaviour? Unavoidable in cygwin? (Obviously not, if I'm on 
> > the right track with my guesswork...) If it is a bug, will it be fixed?¨ 
> > 
> > 
> > 
> > -- 
> > View this message in context: http://cygwin.1069669.n5.nabble.com/fork-and-file-descriptors-with-un-flushed-output-tp92349.html
> > Sent from the Cygwin list mailing list archive at Nabble.com. 
> > 
> > -- 
> > 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
> >
> 
> 
> -- 
> 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
> 
> 
> 
> If you reply to this email, your message will be added to the discussion below:
> http://cygwin.1069669.n5.nabble.com/fork-and-file-descriptors-with-un-flushed-output-tp92349p92353.html
> To unsubscribe from fork() and file descriptors with un-flushed output, click here.
> NAML





--
View this message in context: http://cygwin.1069669.n5.nabble.com/fork-and-file-descriptors-with-un-flushed-output-tp92349p92380.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
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