recv() on forked process

[Rudolf]

Hello, I have a forked process here with one child, each process runs its own while loop. The parents job is to read STDIN then send it to the server; while the job of the child is to print any recieved messages from the server even while the parent is waiting for stdin. I assumed this would work but it seems as soon as the child attempts to recv() from the server to check for messages - the parent stops and the tcp connection appears broken. Im sure I do not fully understand the inner workings of how perl deals with the tcp connection so I might be making my mistake there, thank you

use v5.14;
use Socket;

$| = 1;
my $user_name = 'default';

socket(SERVER,PF_INET,SOCK_STREAM,getprotobyname('tcp'));
my $iaddr = inet_aton('localhost'); 
my $packed_addr = sockaddr_in(5555, $iaddr); 
connect(SERVER,$packed_addr) or die "Cant connect: $!\n";

print STDERR "[Connected to server as \"$user_name\"];    \tfor a list
+ of commands type /help\n";
send(SERVER,$user_name,1);                                           

if(my $pid = fork){                                                   
  while (1){    
    print "Send: ";
    chomp(my $data = <STDIN>);
    send(SERVER,$data,1);   
  } 
}
else{ 
    while(1){
        if( recv(SERVER,my $info,1024,0) ){
           say $info;
        }
    }
}

[BrowserUk]

as soon as the child attempts to recv() from the server to check for messages - the parent stops and the tcp connection appears broken.

You cannot send from a socket whilst it is blocked in a recv.

That is, you cannot both send to & recv from (one end of) a socket simultaneously.

You can simulate something like it, by setting the socket non-blocking; and polling the socket (select) to determine if there is anything to be read; and only attempting a recv if there is; thus keeping the time spent in the recv state to a minimum and maximising the time when a send will complete successfully.

But this comes at the expense of forcing your application into operating like a party line. Something most monks will be too young to remember. Heck. I only vaguely remember the concept.

But then again, things have a habit of going full circle. For a while there -- roughly the '80s to mid '90s -- companies had these amazingly magical devices called "answer phones" (for the younger amongst you, think "voice mail").

If you called them, and they were out or too busy to take the call, you left them your name and telephone number; and they called you back. Simples.

Now -- for "our convenience and satisfaction" the inanimate voice lies -- we have to poll the damn phone listening to that awful tiny, usually out-of-date, and always cheesy musac interminably, all the time hoping that same inanimate voice won't come back and lie to us again:

• "Your call is important to us";
• "One of our Customer Relations Enhancement Executive Professionals will be with you momentarily";
• "We are currently experiencing an unprecedented volume of calls; it might take a tad longer than normal to take your call";
• "While we've got you tied to listening to us; have you considered purchasing more of the service you are calling to complain about? Here we will layout in excruciating detail, the bewildering set of pricing plans that all come with our we-will-not-be-beaten price guarantee and of course; our award winning service.".

[zentara]

the party line .... Something most monks will be too young to remember

Now it's something you tow, or an 800 number. :-)