in reply to Re: Does IO::Select work? Anywhere?
in thread Does IO::Select work? Anywhere?

This code runs rock solid for me on Linux, it's about as simple an IO::Select example that you can get.

Thank you. But ... :)

If there is a complete, correct example out there, I'm damned if I can find it.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

RIP Neil Armstrong

Replies are listed 'Best First'.
Re^3: Does IO::Select work? Anywhere?
by zentara (Cardinal) on Oct 21, 2012 at 15:16 UTC
    If there is a complete, correct example out there, I'm damned if I can find it.

    :-) Yeah, that is why I like using the eventloop method that Glib and Wx use, where their eventloop can detect conditions like IN , HUP, ERR, etc. I would think if you looked at the c based source code for glib's io::watch method, you will probably find the c code, which allows the eventloop's intelligence to report back IN or HUP, or ERR.

    From some discussion I remember from back in my c experiments, there are some sort of error flag set, with values like eagain, einttr, etc. See blocking sockets . That code looks like it could be rewritten in a Perl script, although you may need require 'sys/ioctl.ph';.

    P.S. See the low level Perl code, multiplexing server at perl examples


    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku ................... flash japh
      that is why I like using the eventloop method that Glib and Wx use

      I guess it explains the popularity of such frameworks, when the primary perl tool -- IO:Select -- has been broken for 12 years or more.

      And probably why all the examples are so bare bones. Every time anyone has tried to write anything more complex, it breaks. So they either give up or resort to some higher-level framework.

      P.S. See the low level Perl code, multiplexing server at perl examples

      Thanks. Unfortunately, the first thing I see in the I/O Multiplexing Server example is:

      sub readline { # 'select'-compatible function for reading one line of input from # a filehandle. # # readline() expects one argument -- filehandle S # # sample call: $mystring = readline('S') # my $filehandle = $_[0]; my $c=''; my $retstr=''; my $endoffile=0; while ($c ne "\n" && ! $endoffile) { if (sysread($filehandle, $c, 1) > 0) { $retstr = $retstr . $c; } else { $endoffile=1; } } return $retstr; }

      What if the client gets interrupted before it sends the newline?

      You've got a something like 900 seconds default before the connection times out and the endoffile flag gets raised; during which time, nothing else happens. No new clients get accepted, no existing clients get serviced.

      And this is teaching material??


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      RIP Neil Armstrong

        And this is teaching material??

        Sure, it taught me alot. To get away from your obsession on readline, try this slightly modified version. I can kill the client's xterm, before I send any newline, and the server stays responsive to new and other connections.


        I'm not really a human, but I play one on earth.
        Old Perl Programmer Haiku ................... flash japh