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
prev parent 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).