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


Clear questions and runnable code get the best and fastest answer
	PerlMonks

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

by BrowserUk (Patriarch)

on Mar 24, 2014 at 19:12 UTC ( [id://1079582]=note: print w/replies, xml )

Need Help??

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