X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date:	Thu, 13 Dec 2001 10:14:31 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	sandmann AT clio DOT rice DOT edu
Message-Id:	<8582-Thu13Dec2001101431+0200-eliz@is.elta.co.il>
X-Mailer:	emacs 21.1.50 (via feedmail 8 I) and Blat ver 1.8.9
CC:	djgpp-workers AT delorie DOT com, tim DOT van DOT holder AT pandora DOT be,
	laszlo DOT molnar AT eth DOT ericsson DOT se
In-reply-to:	<10112121907.AA18276@clio.rice.edu> (sandmann@clio.rice.edu)
Subject:	Re: A buffering problem?
References:	<10112121907 DOT AA18276 AT clio DOT rice DOT edu>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Wed, 12 Dec 2001 13:07:46 -0600 (CST)
> 
> > >   (void)fclose(stdaux);
> > >   (void)fclose(stdprn);
> > > 
> > > It's our stdio cleanup hook that finds the (non-existent) stdprn entry
> > > in the chain of FILEs first and closes it behind the back of the 'real'
> > > file with fd 3.
> > 
> > That's not what my records indicate.  The problem we saw there was
> > that a file handle was being closed as I wrote.  Perhaps that's a
> > different problem.
> 
> If I remember correctly the problem was our exit handler which closed
> files (and flushed them) walked the file handles, encountered stdaux
> one with handle 3, closes it, then the real file handle later doesn't
> get flushed (handle already closed).

This cannot be the whole story, or maybe I'm missing some detail.

If stdaux is closed with fclose, that sets the _flag member of its
FILE object to zero.  _fwalk (invoked by stdout hook at exit time)
ignores any FILE objects whose _flag is zero.  So it won't do
anything with the stale stdaux.

Unfortunately, even after reading the archives on DJ's server, I
cannot figure out what else was involved.  Unless this happens in a
child program whose parent closed stdaux, that is; is that the case in
point?

> Many proposals were tossed out (having close scan the file objects, but
> that didn't fix the pre-allocated handles)

I don't find this aspect discussed in the archives.  How would
scanning file objects from within close miss the pre-allocated
handles?

> The thread died without anyone doing any coding.  If the fclose()s were
> left in perl any pre-v2.04 image would not flush properly - so it's 
> probably best that the fcloses were suppressed.

Laszlo, does the problem happen in Perl itself, or in programs it
runs?  That is, the buffering problems you see, are they with output
written by Perl or by some program run by Perl?

- Raw text -