Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try to synchronize threads initializations #14098

Closed
wants to merge 1 commit into from
Closed

Conversation

yuyichao
Copy link
Contributor

Using uv_barrier_wait as @tkelman suggested in #14091 (comment) . I've also thought about ti_threadgroup_barrier but I'm not sure if it is available at this point (without introducing more race conditions)....

Tested on top of #14083 and it seems to fix the segfault for me.

Fixes #14091

@yuyichao yuyichao added the multithreading Base.Threads and related functionality label Nov 22, 2015
@tkelman
Copy link
Contributor

tkelman commented Nov 22, 2015

I rebased this on top of #14083 locally, and with LLVM 3.3, threading enabled, in a mingw build (either 32 or 64 bit), it changes the situation from a racy segfault to a repeatable failure in bootstrap:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Having trouble getting a backtrace of where this is happening. In gdb I can step through initialization and it freezes in ntdll!ExpInterlockedPopEntrySListEnd16 during uv_signals_init.

@yuyichao
Copy link
Contributor Author

Close in favor of #12904 (assuming it doesn't take too long to sort out).

@yuyichao yuyichao closed this Nov 23, 2015
@yuyichao yuyichao deleted the yyc/thread-init branch November 23, 2015 02:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
multithreading Base.Threads and related functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Race condition in threads initialization.
2 participants