Front page | perl.perl5.porters |
Postings from November 2000
Re: PerlIO - what next ?
Thread Previous
|
Thread Next
From:
Nick Ing-Simmons
Date:
November 9, 2000 06:02
Subject:
Re: PerlIO - what next ?
Message ID:
200011091401.OAA14343@mikado.tiuk.ti.com
Barries <barries@slaysys.com> writes:
>On Thu, Nov 09, 2000 at 12:51:03PM +0000, Nick Ing-Simmons wrote:
>> Barries <barries@slaysys.com> 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
>that.
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
GetStandardHandle().
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 <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.
Thread Previous
|
Thread Next