develooper Front page | perl.perl5.porters | Postings from July 2001

PerlIO and shutdown

Thread Next
From:
Ilya Zakharevich
Date:
July 21, 2001 12:28
Subject:
PerlIO and shutdown
Message ID:
20010721152846.A11492@math.ohio-state.edu
I still did not disable PerlIO in my pre-5.7.2, though it is quite
useless with PerlIO.  So now I see another significant problem;
however, thinking more about it, I do not know how the "sane" file
stuff handles this situation.

The question is: what to do with files on the interpreter exit (with
Perl_destruct_level > 0).  What I can see is that 

  a) PerlIO is not flush()ing buffers, postponing this until atexit-time;

  b) PerlIO is close()ing file descriptors at atexit-time;

What happens with PerlIO-less Perl?  What do we *want* to happen?

It is obvious that "a" and "b" are both unacceptable.  With
Perl_destruct_level > 0 one expects to have many sequential
interpreters (or one intepreter inside much longer living process), so
having output sitting in some Perl-initiated buffer is not a good thing.

So the file buffers should be at least flushed.  Should they be closed
on the interpreter exit or at the atexit-time?

It is clear that closing at the atexit-time has too many unwanted side
effects: stdin/stderr/stdout are closed too, forbidding diagnostics
from the earlier-installed atexit() handlers and CRT cleanup routines.

On the other hand, not closing *on the interpreter exit* creates a
possible leak of file-descriptors in the multiple sequential
interpreters scenario.  So some FDs should be closed on each
interpreter exit, some not closed even during atexit time.

How the stdio-Perl handles it?  How it is done that stderr is not
closed when *main::STDERR goes out?  Is there another piece fo $^F
voodoo involved?

Puzzled,
Ilya

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About