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

Re: Smoke [5.9.0] 18609 FAIL(F) MSWin32 5.1 (x86/1 cpu)

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
February 4, 2003 12:42
Subject:
Re: Smoke [5.9.0] 18609 FAIL(F) MSWin32 5.1 (x86/1 cpu)
Message ID:
20030204203900.GA282@Bagpuss.unfortu.net
On Sun, Feb 02, 2003 at 11:37:20AM +0000, Nick Ing-Simmons wrote:

> You will hardly ever get it in "one shot". Almost all PerlIO layers buffer 
> in chunks of 4K..8K (:mmap is an exception). So even PerlIO_read()
> is - under the hood - still going to Copy() into the sv 4K at a time.

I see this as an implementation detail that can be changed at a later date.
[I've not checked how hard it is to change, I just perceive of it in this way]

glibc's fread supplies whatever it has already in the buffer, and then does
a single read call direct from its data supplier (typically read(2)) into the
rest of the user's buffer. I've not checked the FreeBSD libc source, but I
don't see why PerlIO shouldn't do this sort of thing in the future.

> The main win of your patch is avoiding lots of malloc()-s, which is 
> retained.
> 
> What I most dislike about the read_record scheme is that can give wrong 
> return data if the "guess" is too small - it does not re-try looking 
> for more. Also if you look at the the patch you will notice that the 
> read-record block also has VMS specific code which bypasses layer stack
> to get special file-system record behaviour. So 'goto' that for $/ = undef
> breaks :encoding() on VMS.

What happened to my suggestion of just taking the file size as a parameter
for an initial fread, and then continuing into the normal read loop -
a: if it's now at EOF (doesn't matter if the fread was short or full length)
   it's time to stop because we've slurped the lot
b: if it's not at EOF just keep reading.

?

Nicholas Clark

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