Re: Ideas for 5.10

Front page | perl.perl5.porters | Postings from August 2002

Thread Previous | Thread Next

From:

Nick Ing-Simmons

Date:

August 13, 2002 02:04

Subject:

Re: Ideas for 5.10

Message ID:

20020813090351.1628.3@bactrian.elixent.com

Benjamin Goldberg <goldbb2@earthlink.net> writes:
>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?

That it hung IO ops freezing the GUI. 
byte-at-a-time read and non-blocking IO both solved it with other 
snags.

>
>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
>TCP sockets, 

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 
blocking mode. 

I suspect though that on such a socket read() will wait for whole requested 
length.

Win32 select() may also not work "right" for listen mode sockets.

>and not work right with pipes or disk files.

True.

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
>thing.

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
>> 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.

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.
-- 
Nick Ing-Simmons
http://www.ni-s.u-net.com/

Thread Previous | Thread Next