in reply to Re^2: socket select hangs after client restarts
in thread socket select hangs after client restarts

Yes, I know, but I do not think it is the correct way to deal with the OPs problem. Better, I believe, to handle EBITS and shutdown & close streams with errors.

But, as I've only done this stuff on Windows, and from the mention of fork I'm assuming the OP is on *nix, and WinSocks have a habit of behaving subtly (and not so subtly) differently, I'm not prepared to put any weight behind that assertion.


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.
"I'd rather go naked than blow up my ass"
  • Comment on Re^3: socket select hangs after client restarts

Replies are listed 'Best First'.
Re^4: socket select hangs after client restarts
by planetjeff (Initiate) on Feb 18, 2010 at 22:01 UTC
    Heya - thanks for the responses! First, this is on Ubuntu Linux - sorry for not including that. Perl v5.10.0 I've update the code according to your suggestion:
    while (1) { # Set up bit vectors for polling my $rin = ''; my $ein = ''; my $rout; my $eout; vec ($rin, fileno ($sock) , 1) = 1; vec ($ein, fileno ($sock) , 1) = 1; foreach my $streamID (keys %openStreamsSock) { vec ($fin, fileno($openStreamsSock{$streamID}) , 1) = 1; vec ($ein, fileno($openStreamsSock{$streamID}) , 1) = 1; } # Wait for incoming message my $nfound = select ($rout=$rin, undef, $eout=$ein, 5); if ($nfound) { # Check client streams, close any in error foreach my $streamID (keys %openStreamsSock) { if (vec($eout, fileno($openStreamsSock{$streamID}),1)) { close ($openStreamsSock{$streamID}); delete ($openStreamsSock{$streamID}); } } if (vec($rout, fileno($sock),1)) { $openStreamsSock{$streamRequest++} = $sock->accept(); } else { foreach my $streamID (keys %openStreamsSock) { if (vec($rout, fileno($openStreamsSock{$streamID}),1)) { # read data off the socket; not a message here, just r +aw data $msgSize = sysread ($openStreamsSock{$streamID}, $msgReceived, 1048576); if (defined ($msgSize) && ($msgSize > 0)) { writeStreamData ($streamID, $msgReceived); } else { # $msgSize being 0 indicates end of stream, or # $msgSize being undef indicates error, so close close ($openStreamsSock{$streamID}); delete ($openStreamsSock{$streamID}); } } } } } else { print "$0: Normal timeout of select...\n"; } }
    Unfortunately, this doesn't seem to change the behavior in any way. I hope I'm using it correctly. What really gets me is that the timeout also stops functioning. It leads me to suspect the code got stuck somewhere else in the script. All indications from my debug statements (removed for readability) showed the script going all the way back to the select statement and then never coming back, but I can't be absolutely sure. If anyone else has ideas, I'm all ears. (uh, eyes)
      my debug statements (removed for readability) showed the script going all the way back to the select statement and then never coming back,

      It ought to be fairly easy to tell if the timeout is failing to trigger. Just bracket the select line with

      warn "before select: " . time; select... warn "after select: " . time;

      And if it is, then that to me indicates that something is very broken. But I don;t know enough about it to say what.

      I'd suggest that you confirm your suspicion, and then post a new SoPW with "select timeout failng on Ubunto vxxx & Perl vx.x.x". With as much logging from the period immediately preceding the failure--perhaps a tcp trace--as you can gather.


      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.