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.

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.

I understand that. However it could be that there is no problem with thread, but there is a problem with the implementation of fork (using thread). Put it in this way, say, there is an issue with a piece of your Perl code, obviously it could be caused by a bug in Perl itself, but it could also be a bug you introduced into your code, right? the same thing here.

That's why I said you jumped to conclusion, unless you clearly come up a piece of threading code, without fork(), to show us that the problem is not really caused by the implementation of fork() itself, but the underlying thread.

I am not saying that you must be wrong, but rather saying your conclusion is not logically well supported. For me to say that "you must be wrong", I have to come up with a piece of threading code to demo that it does not have the problem even without timeout, which I didn't do. Because I didn't do, I don't have the right to jump to the opposite conclusion. The same logic applies to both of us, right ;-?