develooper 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


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