Front page | perl.perl5.porters |
Postings from August 2002
Re: Ideas for 5.10
Thread Previous
|
Thread Next
From:
Benjamin Goldberg
Date:
August 12, 2002 21:26
Subject:
Re: Ideas for 5.10
Message ID:
3D588ACA.314D71A6@earthlink.net
Nick Ing-Simmons wrote:
>
> Benjamin Goldberg <goldbb2@earthlink.net> writes:
> >> > my $m = sysread $handle, $$bufref, LOTS, length $$bufref;
> >>
> >> And that sysread hangs. The select() just says a sysread() of one
> >> byte will not hang - nothing more.
> >
> >Are you sure about that?
>
> No.
>
> Across the whole slew of platforms perl runs on I am sure at least
> one of them behaves that way for some kind of thing that fd may be
> connected to. Or I would not have had all the hassle with Tk's
> fileevent over the years. I would be delighted to be proved wrong.
What kind of hassle did you have with Tk's fileevent?
> >While I agree that that select() merely indicates that there is at
> >least one byte ready for reading, I think you're mistaken about what
> >sysread does. AFAIK, sysread() will read at least one byte (blocking
> >if necessary to do so), but if you request more bytes than are
> >available, it will read however many it has available, and return the
> >number that were read (and *not* block to get the full count
> >requested).
>
> "man 2 read" on this Linux says it _may_ do that (for pipes and
> terminals) but is rather vague. If I recall correctly my problems
> have been with pipes and TCP (stream) sockets (particularly on Win32).
I've been told that (on *nix) select() will *always* indicate that an fd
for a disk file is readable -- I would assume that if you try to sysread
a huge number of bytes from such an fd, it will block until that many
bytes are read.
And I've been told that on Windows, select will only work properly with
TCP sockets, and not work right with pipes or disk files.
I'll concede that the fact that Windows's select doesn't work right with
pipes is a major annoyance, but *most* of the times that one would be
using select is with sockets, in which cases it should do the right
thing.
> >It's the C-level fread(), and the perl-level read(), that block until
> >the total amount requested has been gotten.
>
> Agreed.
>
> >I seriously doubt that you really have to sysread one byte at a time.
> >I will look for docs stating that things are one way or another, but
> >I think that I'm right.
>
> The problem is almost certainly not going to be on a UNIX-oid with
> reasonably solid BSD socket heritage. It is going to be Win32, MacOS,
> VMS VOS, OS/2 or some other platfrom where POSIX-y calls are not
> native and perhaps not really understood by folk that implemented the
> emulation.
On systems where it's supported, ioctl FIONREAD might allow us to know
how many bytes are available for reading, so that more than one byte
could be read, without blocking.
> (A classic example - a DOS C runtime where read's fd was treated as
> index into FILE * table which then did ANSI C's fread() which was
> implemented as native INT 21h calls.)
Ok, now that example is just bizarre :)
If it becomes necessary, we *could* have some platform specific code
which somehow reads data in a sensible (UNIX-oid) manner.
--
tr/`4/ /d, print "@{[map --$| ? ucfirst lc : lc, split]},\n" for
pack 'u', pack 'H*', 'ab5cf4021bafd28972030972b00a218eb9720000';
Thread Previous
|
Thread Next