X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10112121907.AA18276@clio.rice.edu>
Subject:	Re: A buffering problem?
To:	djgpp-workers AT delorie DOT com, eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date:	Wed, 12 Dec 2001 13:07:46 -0600 (CST)
Cc:	tim DOT van DOT holder AT pandora DOT be, laszlo DOT molnar AT eth DOT ericsson DOT se
In-Reply-To:	<8011-Wed12Dec2001191939+0200-eliz@is.elta.co.il> from "Eli Zaretskii" at Dec 12, 2001 07:19:39 PM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
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

> >   (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).

We then discussed about how close() called could cause this problem, but
it could also be caused by our setup code assuming handles 3/4 were 
assigned when we set up STDAUX/STDPRN to begin with.  (Child process
created with handles 3/4 closed?)

Many proposals were tossed out (having close scan the file objects, but
that didn't fix the pre-allocated handles) - walking the file handles
in reverse order (to close the most likely files associated with a handle
first) but this would require either storing them in reverse order or
adding a backlink.

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.  Yes, it shows a bug
in the library (still not fixed) but expecting a 100% new toolkit is
difficult.  But if we can find a good fix (and quick way to test/show
it's fixed) it ought to get at least into cvs asap.  Putting it in update
depends on how simple/low risk it is.

- Raw text -