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

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 ;-?

Comment on Re^6: Win32 fork and IO::Socket::INET->accept calls

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]