in reply to Re: Win32 fork and IO::Socket::INET->accept calls
in thread Win32 fork and IO::Socket::INET->accept calls

I can easily make your code work, just by adding a Timeout to your socket, which you should have any way. A server socket without timeout can run into many problems. Other than the problem you demo'd here, it could also become a dead socket (a socket that cannot be awakened by accept()), if you leave it idle for long enough.

use strict;
use warnings;

use IO::Socket::INET;

$|=1;

my $server = IO::Socket::INET->new( 
   Proto => 'TCP', 
   LocalPort => 2500, 
   Reuse => 1, 
   Listen => 10,
Timeout=>1
);

if (fork() == 0) {
   print("$$: Child 1.$/");
   $server->accept();
} else {
   sleep(1);   # Make sure accept is reached.
   if (fork() == 0) {  # <------ Doesn't returns until accept returns.
      print("$$: Child 2.$/");
      sleep(3);
   } else {
      print("$$: Parent.$/");
      sleep(3);
   }
}

print("$$: oye.$/");

[download]

Replies are listed 'Best First'.
Re^3: Win32 fork and IO::Socket::INET->accept calls
by ikegami (Patriarch) on Nov 04, 2004 at 04:27 UTC

    But why would accept in one pseudo-process (thread) tie up a function (fork) in another pseudo-process (thread)? Does any other function have the same effect?

    I'm definitely interested in hearing how "a server socket without timeout can run into many problems". Could you elaborate?

[reply]

      One problem I ran into many times in the past is that, with this kind of code:

      my $s = IO::Socket::INET->new(Proto => "tcp", LocalAddr => "localhost"
+, LocalPort => 3000, Listen => 10);

for (my $c = $s->accept()) {
      ...
}

      [download]

      If you leave it alone for hours and there is no client come to connect, you might never be able to accept() connection any more, even when there is client wants to conenct. I ran into this many times in the past. To resolve this, I simply let the accept() timeout periodically.

      "But why would accept in one pseudo-process (thread) tie up a function (fork) in another pseudo-process (thread)? "

      Don't jump to conclusion that this has anything to do with thread, unless you come up a piece of threading code to demo the same problem.

[reply]
[d/l]

        The code I showed IS threading code. Don't forget that fork creates a new *thread* in Win32, not a new *process*. And this problem happens specifically in Win32.

        From perlfork:

        The fork() emulation is implemented at the level of the Perl interpreter. What this means in general is that running fork() will actually clone the running interpreter and all its state, and run the cloned interpreter in a separate thread, beginning execution in the new thread just after the point where the fork() was called in the parent. We will refer to the thread that implements this child ``process'' as the pseudo-process.
[reply]

In Section Seekers of Perl Wisdom