Front page | perl.perl5.porters |
Postings from August 2002
Re: Ideas for 5.10
From: Nick Ing-Simmons
August 13, 2002 02:04
Re: Ideas for 5.10
Message ID: firstname.lastname@example.org
Benjamin Goldberg <email@example.com> writes:
>Nick Ing-Simmons wrote:
>> Benjamin Goldberg <firstname.lastname@example.org> 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?
>> 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?
That it hung IO ops freezing the GUI.
byte-at-a-time read and non-blocking IO both solved it with other
>I've been told that (on *nix) select() will *always* indicate that an fd
>for a disk file is readable
True - it is.
>-- 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.
But not for long.
>And I've been told that on Windows, select will only work properly with
It is more complicated than that. There are are least two implementations
of sockets on Win32 (two different DLLs), and even with same DLL name
their behaviour differs between Win9X and WinNT families - and WinCE
is probably different again :-(.
Sockets can be in different modes and select only works "right" in
I suspect though that on such a socket read() will wait for whole requested
Win32 select() may also not work "right" for listen mode sockets.
>and not work right with pipes or disk files.
Hence the "plan" for Tk on Win32 is to switch to native "Event" scheme
rather than use select(). But that means sockets must NOT be in blocking
mode and so read() will not work at all.
>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
It _should_ but it doesn't.
>> 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
>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.
ioctl() is the most UNIXy of the fd family. Which ioctl's are honoured
depends on the device driver.
FIONREAD is variously implemented when I tried it as a solution I could
not even get it to be usable between Linux and Solaris :-(
>If it becomes necessary, we *could* have some platform specific code
>which somehow reads data in a sensible (UNIX-oid) manner.