Front page | perl.perl5.porters |
Postings from May 2003
Re: Meaning of sysread()
Thread Previous
|
Thread Next
From:
Nick Ing-Simmons
Date:
May 21, 2003 09:54
Subject:
Re: Meaning of sysread()
Message ID:
20030521165417.2695.5@bactrian.elixent.com
Mark Mielke <mark@mark.mielke.cc> writes:
>
>Here is another argument:
>
>sysread() is documented ('man perlfunc') to '[attempt] to read LENGTH
>characters of data ... [bypassing] buffered IO ...'. If Perl sysread()
>is actually implemented using C read(), then it would be impossible to
>read LENGTH characters of data, and only LENGTH characters of data
>without calling C read() once for each byte. Remember - no buffering.
You read LENGTH bytes and see how many characters that is.
You find it is LENGTH-N chars so you read N more bytes and see where
you are ...
>You can't put the bytes back. Therefore, the documentation is wrong,
>or sysread() is implemented extremely inefficiently.
It isn't too bad the series converges quite quickly ;-)
>
>For Perl read(), we don't care, because read() is buffered and is not
>affected by the same performance issues mentioned earlier. Reading one
>byte at a time is not expensive for buffered PerlIO handles.
Nor necessary! as PerlIO can "unread" abitrary amount of data,
and :encoding snoops the buffer a perl-ish manner, and ...
>
>To validate this entire line of thinking I suggest that the following
>point be seriously considered:
>
> - sysread() is supposed to be a more direct system read that avoids
> the intermediate layers of processing. This definately includes STDIO,
> and as far as I am concerned, it definatesly includes filtering.
That is certainly my _personal_ view too - but as designer/maintainer
I started this thread to (A) make sure that I was not alone in that view
and (B) to try and collect arguments for the other side as well.
The ticket was caused by Net::FTP script using sysread() and perl5.6.1
on Win32 did CRLF translation on that and it worked. 5.8 does not
so file becomes CRCRLF on the wire and CRLF when de-ASCIIed at other end.
--
Nick Ing-Simmons
http://www.ni-s.u-net.com/
Thread Previous
|
Thread Next