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;
}
[download]

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

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.

Read more... (22 kB)

---

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

To get away from your obsession on readline,

Observation is not obsession.

I can kill the client's xterm, before I send any newline, and the server stays responsive to new and other connections.

Sure you can if you fork, but that's a different solution. Ie. a forking server not a multiplexing server.

Here is a perfectly serviceable equivalent using threads:

#! perl -sw
use strict;
use threads stack_size => 4096;
use threads::shared;
use IO::Socket;

use constant CRLF => chr( 13 ) . chr( 10 );
$/ = $\ = CRLF;

my $server = IO::Socket::INET->new(
    LocalHost => 'localhost',
    LocalPort => 1025, Listen => SOMAXCONN, Reuse => 1,
) or die "Couldn't create listening socket";

while( 1 ) {
    my $client = $server->accept;
    async {
        my $peerhost = $client->peerhost .':'. $client->peerport;
        while( <$client> ){
            chomp;
            print $client $_;
            print "$peerhost:$_";
        }
    }->detach;
}

close $server;
[download]

That will (has) run all day and night without problems.

And here is a 'one-liner' that will launch 1000 clients at it each time:

perl -Mthreads=stack_size,4096 -MIO::Socket 
-E"
async{ 
    my$s=new IO::Socket::INET('localhost:1025') or warn $^E, return; 
    say $s 'Hello'; 
    print scalar <$s>; 
    shutdown $s, 2; 
    close $s; 
}->detach for 1 .. 1e6"
[download]

But as with all forking servers, it is ridiculously resource intensive for an echo daemon.

---

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