develooper Front page | perl.perl5.porters | Postings from November 2000

Re: PerlIO - what next ?

Thread Previous | Thread Next
Nick Ing-Simmons
November 9, 2000 06:02
Re: PerlIO - what next ?
Message ID:
Barries <> writes:
>On Thu, Nov 09, 2000 at 12:51:03PM +0000, Nick Ing-Simmons wrote:
>> Barries <> writes:
>> >Now if only I could close all filehandles, I could make subprocesses a little
>> >more isolated from the parent and more reliably daemonizable :).
>> When built with -Duseperlio it would be trivial to have a "close all"
>> there already has to be one as an "atexit" routine to flush the 
>> buffers. To build on the way PerlIO_flush(NULL) does flush all 
>> PerlIO_close(NULL) could so the same - but what should it look like to perl
>> code (or should we just make perl do the right thing?)
>Could you allow Perl-level access to a list of open filehandles that the
>program could iterate over?  

Not easily at PerlIO level. There can be multiple PerlIO * for 
one perl-level handle (e.g. input and output for sockets), 
and PerlIO * for which no perl handle exists (e.g. opened by XS code
e.g. Tk code to load foo.gif).

I did ask if we should merge perls *Glob{'IO'} PerlIO and Sarathy thought not.
So do I now as currently PerlIO * elegantly allows a "layer" to treat 
the things below it as a PerlIO *.

>Thinking of how I'd use this in IPC::Run,
>I'd like to be able to do something like this (psuedo-code follows):
>   ## In parent, before forking any children:
>   for my $fh ( IO::Handle->all_open_handles ) {
>      if ( $fh->is_open_for_output ) {
>         $fh->flush ;
>      }
>   }
>   fork() ;
>   ## In child, post-fork, pre-exec:
>   for my $fh ( IO::Handle->all_open_handles ) {
>      unless ( should_leave_open $fh ) {
>         $fh->close ;
>      }
>   }
>This is more general than providing fflush(0)-like behavior that might
>be exposed by a IO::Handle->flushall() or ->closeall().  

As it stands at present 'package IO' lives way above the level I am 
discussing. A perlIO is inside an SvIO which is part of a glob.
An IO "object" is a blessed reference to such a glob...

The IO / Filehandle object wrapper is something I am striving to make
unnecessary (without breaking it of course) - hence 

open(my $fh, ...)

>I don't see a
>need for flushall() or closeall() to be do-able without referring to a
>some module.

perlio->flushall would be easy to do.

>I'd like to see the list of filehandles and the filehandles themselves be
>more inspectable.  For the latter, this would include what's layered
>between them and the underlying OS handle.  But that's all less important
>that Just Getting It Working.  And thanks for the work you're doing for

The main thing the Win32 port needs to do is be based on native Win32
'Handle' level IO and not on read() etc. in C run time.
The read() layer is a pain as it differs between vendors and 
version of compiler and just gets in the way.

>As another item, do the things that you are keeping in mind for the
>Windows port include anything that might enable select-on-filehandles
>when running under Windows like cygwin does?

Perhaps. I am not 100% convinced that the 'file descriptors as small integers'
that select() implies is a usefull thing to maintain on Win32. (Except
for historic 0,1,2 stdin,stdout,stderr which maps quite well to 

I would rather define a new PerlIO_poll() / perlio->poll() abstraction 
which allowed "how to I wait for this" to be controlled on a 
handle-by-handle basis.

>- Barrie
Nick Ing-Simmons <>
Via, but not speaking for: Texas Instruments Ltd.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About