Front page | perl.perl5.porters |
Postings from June 2003
Re: [perl #22339] IO::Handle::setvbuf not defined properly
Thread Previous
|
Thread Next
From:
Nick Ing-Simmons
Date:
June 16, 2003 09:24
Subject:
Re: [perl #22339] IO::Handle::setvbuf not defined properly
Message ID:
20030616162411.15861.8@bactrian.elixent.com
Mark Jason Dominus <mjd@plover.com> writes:
>> Mark Jason Dominus <mjd@plover.com> writes:
>> >You said:
>> >>
>> >> seek(FH,0,1); # re-position here
>> >>
>> >> Will discard the buffer contents on a read stream.
>> >
>> >Is that guaranteed to work on all platforms, all implementations,
>>
>> Not yet obviously or we would not have this thread.
>
>"Not yet" would seem to be misleading. It can never be guaranteed
>to work everywhere
PerlIO_seek() or pp_seek() can be defined to make it true everywhere.
However I would wish we had a 'flush' keyword so that
$fh->flush
would do the right thing
[If you suggested IO::Handle::flush() be defined to do the right thing
for input streams I would support that.]
>
>> But is guaranteed to work on a :unix:perlio stream.
>
>That seems to me like a strange decision.
Hmm, you may be right there - I have forgotten the original cause
for the problem.
>seek(FH,0,1) is obviously a
>no-op, and therefore a candidate for optimization. The reason
>seek(FH,0,1) worries me so much is that I can imagine reasonable
>implementations that ignore it. For example, if stdio or perlio were
>simply to read buffers on demand, postponing the flush until a reading
>operation occurred outside the current buffer, seek(FH,0,1) would have
>no effect, as would
>
> seek(FH,$N,1); seek(FH,-$N,1);
>
>By promising that seek(FH,0,1) will flush the buffer, you are
>foreclosing the possibility of this design and of adding which might
>be an obvious optimization.
I agree with most of that in principle - but the optimization is just
as obvious to the application code, and nop-seek is a thing that
has meaning for various reasons. e.g. stdio stuff has already lead to
various nop-seeks to switch between read/write on same stream.
There is also code with such nop-seeks to get the stdio stream and
sysread() in sync. ...
>
>The Single Unix Specification does not specify that fseek() will
>discard the buffered data on an input stream, presumably for some
>reason similar to this one.
But does say that to switch between read/write on a RW stream you
must seek.
>
>But if you are sure that is how you want to have it done, that is fine
>with me.
What _I_ want you to do is specify in a PerlIO way that you want
no buffering. If the defaults don't suit - then say what does:
open(my $fh,:"<:unix", # no buffer layer here
>Is it in the documentation? If not, would you be willing to
>put it there?
>
>See below for an alternative.
>>
>> Personally I refuse to adopt a setvbuf() style API which packs too
>> many options into its args - including some which expose addresses
>> of buffers which is not perl friendly.
>
>I understand about the buffers. But all I want is _IONBF, which,
>unlike the other options, is very simple: no buffering at all. I am
>not asking for PerlIO to support line buffering or anything like that.
>
>The current implementation replaces setvbuf with
>
> IO::Handle::setvbuf not implemented on this architecture
>
>Would you be willing to support _IONBF, and leave all other uses of
>setvbuf as "not implemented on this architecture"?
My personal goal is never to have to use IO::* for anything.
[So if someone patched IO.xs to do what you suggest here I don't care.
Whoever does that needs to reconcile what _IONBF means if asked
for on when layer needs buffering to work e.g.
crlf/quoted_printable/gzip/encoding etc.]
Why should I need to
use IO::Handle qw(_IONBF);
$fh->setvbuf(undef,_IONBF(),undef);
When what I really want is
$fh->unbuffered;
If if I wanted it that way then why did I open it buffered in the 1st place?
And in particular if want it buffered but occasionaly
want to discard any pre-read input that sould be easy too.
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
Thread Previous
|
Thread Next