Don't use readline (<>) on filehandles you pass to select.

It can block (which defies the purpose of using select), and it can hide waiting data from select (meaning select won't wake up even though data is waiting to be read).

      foreach $handle1 (@read_from) {
        $buf = <$new_sock>;
        if($buf){ print $buf; }
     }
[download]

      foreach my $handle1 (@read_from) {
        my $buf = '';
        my $rv = sysread($handle1, $buf, 64*1024, length($buf));
        # Handle error if !defined($rv)
        # Handle eof if !$rv
        print $buf;   # Whatever we got, including partial lines
     }
[download]

      foreach my $handle1 (@read_from) {
        our $buf; local *buf = \( $buf{fileno($handle1)} );  # alias
        $buf = '' if !defined($buf);
        my $rv = sysread($handle1, $buf, 64*1024, length($buf));
        # Handle error if !defined($rv)
        # Handle eof if !$rv
        while ($buf =~ s/^(.*\n)//) {
            print $1;   # Full line at a time
        }
     }
[download]

Does that also fix the problem you are reporting?

Thanks very much for your reply. Clearly and improvement on my $buf = <$EC>. I used both of your code snips but the behaviour did not change. I am still not able to write to the socket, only read from it. The code is entering the for @ok_to_write loop (i changed the array name), where I can print to the server terminal using a bare print "\n"; . But it will not print to the socket.

Trying to write to the client
Hello from the client... 1
Trying to write to the client
Hello from the client... 2
Trying to write to the client
Hello from the client... 3
[download]

I tried your code in the isolated client and server (without the fork) and got the same behaviour as before. The data flies between the client and server. I'm pretty sure there's something about the fork that plays a part here. Another difference I notice, is that with forking server, the data from the client is just plodding in.

Here's the code as it now stands in Server_rebuild.pl

#!/usr/bin/perl -w
use strict;

use IO::Socket;
use IO::Select;

# Server_rebuild.pl

my( $EC, $pid);

my $SERVER = new IO::Socket::INET (
    LocalHost => 'localhost',
    LocalPort => '50000',
    Proto => 'tcp',
    Listen => 3,
    Reuse => 1,
    );
die "Could not create socket: $!\n" unless $SERVER;

while(1) { # loop for the parent

  # create a connection to incoming EC
   accept($EC, $SERVER);
   next if $pid = fork;                    # parent
   die "fork: $!" unless defined $pid;     # failure


#=================== Now, it's all about the child processes =========
+=========#

# the socket of the parent is no use to child
close($SERVER);

# my $new_sock = $sock->accept();

my( $select, @ok_to_read, @ok_to_write, $buf, $handle2 ); #$handle1,


 $select = IO::Select->new();
 $select->add($EC);


while ($EC){

      @ok_to_read = $select->can_read(1);
      @ok_to_write = $select->can_write(1);

     foreach my $handle1 (@ok_to_read) {
        my $buf = '';
        my $rv = sysread($handle1, $buf, 64*1024, length($buf));
        # Handle error
        # Handle eof
        while ($buf =~ s/(.*\n)//) {
            print $1;   # Full line at a time
        }
     }
        
      foreach $handle2 (@ok_to_write){  
         print  $handle2 "Hello from the SERVER new_sock\n";
         print  $EC "Hello from the SERVER new_sock\n";
         print "Trying to write to the client\n";
      }
    
    #sleep (1);
   
}

} #$loop for the parent
[download]

I believe I have the behaviour problem solved. I wasn't using autoflush. I don't fully understand it because the data passed back and forth very well when just using accept(), but not with accept() and fork(). In any case, $EC->AUTOFLUSH; allowed me to write out of the server to the client.

Thanks for your help. I've added your code.

Suffering from buffering?

use IO::Handle;
$EC->autoflush(1);
[download]

(doh! I had opened the window a while ago and forgot to check for replies before trying to debug)