[Developers] flush-ing stdout in cctk_vinfo

Jonathan Thornburg jthorn at aei.mpg.de
Wed Jan 31 11:58:07 CST 2007


Hi,

On Jan 31, 2007, at 11:21:47, Bela Szilagyi wrote:
> After some hours of fooling myself (while checking stdout of various
> processes
> from the same run), I realized that a
> 
> fflush(stdout);
> 
> after debugging CCTK_VInfo(...) messages is crucial if one cares for every
> single line of output.  One of my processes hangs and I want to know which
> process is at what point in the source  code.
> 
> The loss of output lines is there even if I request, in the
> comand line, that, output would not be buffered.
> 
> Apparently the non-buffering options are implemented in a way that would not
> work across all systems, (e.g., peyote nodes).
> 
> Can we add the "flush" to the end of the cctk_vinfo?

On Wed, 31 Jan 2007, Erik Schnetter wrote:
> We discussed this, and we decided that this would be too expensive in general.
> Instead we added a command line option "-b" which lets you specify whether to
> flush never, after every line, or after every print statement.  This is for
> all output, not just for CCTK_INFO.

Well, Reading The Fine Source Code reveals that the -b (a.k.a. --buffering)
option turns into a call on CCTKi_CommandLineSetBuffering(), which is
defined in src/main/CommandLine.c starting at line 481 in the current
CVS version.  What this code actually does is this:

void CCTKi_CommandLineSetBuffering (const char *argument)
{
  if (! strcmp (argument, "no"))
  {
    /* Switch to unbuffered mode (best for debugging) */
    setvbuf (stdout, NULL, _IONBF, 0);
  }
  else if (! strcmp (argument, "line"))
  {
    /* Switch to line buffered mode (good for screen output) */
    setvbuf (stdout, NULL, _IOLBF, 0);
  }
  else if (! strcmp (argument, "full"))
  {
    /* Switch to fully buffered mode (fastest) */
    setvbuf (stdout, NULL, _IOFBF, 0);
  }
  else
  {
    CCTK_VWarn (1, __LINE__, __FILE__, "Cactus",
                "Stdout buffering mode '%s' not recognised, "     
                "not changing the default setting", argument);
  }
}

That is, it actually sets the C stdio buffering for  stdout .  It does
not set the C stdio buffering for  stderr  , but as I understand the C
standard, this is supposed to be line buffered by default anyway.  The
code also does not force an explicit  fflush(stdout)  after each
CCTK_VInfo(), either here or in the implementation of CCTK_VInfo()
(which is in src/main/WarnLevel.c, starting at line 229).

In my opinion, the fact that Bela used  --buffering line , yet (as I
understand it) found additional output appearing when he did explicit
flushes, constitutes a bug of some sort.  I'm not quite sure whether
it's caused by stdout and stderr not being synchronized, or a bug in
stdio that isn't handling line buffering properly, but from the user's
perspective, asking for  --buffering line  and not getting it constitues
a bug.

Given this, IMHO Bela's suggestion is a reasonable workaround, which
would certainly avoid the bug in many, albeit not all, cases.  That is,
we would change the code so that if  --buffering line  is specified,
CCTK_VInfo() does an explicit  fflush(stdout)  just before returning.

-- 
-- Jonathan Thornburg <jthorn at aei.mpg.de>      
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam



More information about the Developers mailing list