Re^4: Win32 fork and IO::Socket::INET->accept calls

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.

Comment on Re^4: Win32 fork and IO::Socket::INET->accept calls Download Code

Replies are listed 'Best First'.
Re^5: Win32 fork and IO::Socket::INET->accept calls by ikegami (Patriarch) on Nov 04, 2004 at 04:49 UTC
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]
Re^6: Win32 fork and IO::Socket::INET->accept calls by pg (Canon) on Nov 04, 2004 at 04:56 UTC
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 ;-?	[reply]
Re^7: Win32 fork and IO::Socket::INET->accept calls by ikegami (Patriarch) on Nov 04, 2004 at 05:05 UTC
I never said the problem was with threading. But threads are required to create the problem, so it's fitting -- no, necessary -- that threads appear in the problem description. All I did was describe the problem more precisely than had been done before (although I failed because I forgot to mention the socket had to be inherited). I suspect the problem is the `fork` is waiting for `accept` to release an exclusive lock on some resource so it can duplicate that resource or otherwise proceed with the fork. I won't even conjecture on whether it's fixable.	[reply] [d/l] [select]