[Developers] flush-ing stdout in cctk_vinfo

[Erik Schnetter]

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

-- 
Erik Schnetter <schnetter at cct.lsu.edu>

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: redirect.diff
Type: application/octet-stream
Size: 1475 bytes
Desc: not available
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070204/1417be40/attachment-0001.obj 
-------------- next part --------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20070204/1417be40/attachment-0001.bin