develooper Front page | perl.perl5.porters | Postings from June 2003

Re: [perl #22339] IO::Handle::setvbuf not defined properly

Thread Previous | Thread Next
Nick Ing-Simmons
June 16, 2003 09:24
Re: [perl #22339] IO::Handle::setvbuf not defined properly
Message ID:
Mark Jason Dominus <> writes:
>> Mark Jason Dominus <> 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 


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);


When what I really want is 


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

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