in reply to Re^2: threads->create() blocks on Windows
in thread threads->create() blocks on Windows

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.
  • Comment on Re^3: threads->create() blocks on Windows

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

In Section Seekers of Perl Wisdom