public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: thoni56 <thomas@junovagen.se>
To: cygwin@cygwin.com
Subject: Re: fork() and file descriptors with un-flushed output
Date: Wed, 29 Aug 2012 12:44:00 -0000	[thread overview]
Message-ID: <6BCD31F5-C65C-42D7-BB5A-D899B301564C@junovagen.se> (raw)
In-Reply-To: <503C6DEB.3090101@abacus.ch>

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@n5.nabble.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

      reply	other threads:[~2012-08-29  7:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-28  6:54 thoni56
2012-08-28  7:09 ` Daniel Colascione
2012-08-28  8:12 ` Wolf Geldmacher
2012-08-29 12:44   ` thoni56 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6BCD31F5-C65C-42D7-BB5A-D899B301564C@junovagen.se \
    --to=thomas@junovagen.se \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).