[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