Re^2: threads->create() blocks on Windows

But, the underlying system handle for the socket is locked (by the OS) because the socket is in a blocking read; thus the attempt to clone the handle is blocked until the read completes; which it never will.

Well, this explanation seemed reasonable to me and it seems to indicate that the problem is in Windows itself and that Perl just happens to work in a way that collides with some Windows behavior here if I write my script in a certain way.

I doubt this now! I had tested this script with Strawberry Perl and Active State Perl and both show the same behavior. But now I tested this with Cygwin's Perl package and it just works. So is this actually a bug in Strawberry and Active State Perl, or is Cygwin just applying some magic here to make this work?

Comment on Re^2: threads->create() blocks on Windows

Replies are listed 'Best First'.
Re^3: threads->create() blocks on Windows by BrowserUk (Patriarch) on Mar 24, 2014 at 19:12 UTC
So is this actually a bug in Strawberry and Active State Perl, or is Cygwin just applying some magic here to make this work? Both AS Perl and Strawberry Perl use the MS C-runtime, which is where the internal locking is done. It's not an error, it's a design choice. Cygwin on the other hand implements a strictly POSIX-complient C-runtime which makes other choices. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' 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.	[reply]
Re^4: threads->create() blocks on Windows by photron (Novice) on Mar 25, 2014 at 10:37 UTC
Okay, so Cygwin is applying some magic here. Anyway, I can reproduce the exact backtrace bulk88 posted and I can only see one thread having a msvcrt.dll frame on its callstack. So I isn't obvious to me why this should be a deadlock with the locks in msvcrt.dll. I looked at the msvcrt.dll code and can see the locking you're talking about. But I can't see how this should be the problem here. Also I managed to create another deadlock case in which both threads have no msvcrt.dll frame on their stack, but directly call into ws2_32.dll from the Perl library. Anyway, I'll give up on this problem for now and use Cygwin as a workaround. Thanks for your help!	[reply]