[Developers] flush-ing stdout in cctk_vinfo

Tom Goodale goodale at cct.lsu.edu
Sun Feb 4 16:49:47 CST 2007


Looks good to me.  Bela can you verify that this solves your problem ?

Cheers,

Tom

On Sun, 4 Feb 2007, Erik Schnetter wrote:

> On Feb 1, 2007, at 03:16:31, Tom Goodale wrote:
>
>> On Wed, 31 Jan 2007, Jonathan Thornburg wrote:
>> 
>>> Hi,
>>> 
>>> I wrote
>>>> 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.
>>> 
>>> Sorry, I now realise bela specified   -bno   .  But I think this
>>> makes the case even stronger -- he asked for *no* output buffering,
>>> but yet there clearly was some buffering (since explicit flushing
>>> gave additional output).
>> 
>> There's definitely a bug somewhere, so putting the fflush in would work
>> around it, at least for output using CCTK functions. However I think the
>> problem is with the redirection to the CCTK_Proc... files happening after
>> the buffering has been set - freopen is equivalent to fclose followed by
>> fopen.  I think we just need to move some code about to have code which
>> will work even when non CCTK functions output.
>
> See the attached patch.
>
> Delay setting the output buffering mode until after I/O has been redirected.
>
> Okay?
>
> -erik
>
>


More information about the Developers mailing list