-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
Fix windows profiler deadlock #60056
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
Conversation
|
I agree that this fixes the issue, but it also feels like it may be a libuv bug? libuv already creates a duplicate handle for |
|
This function is a promise to libuv that you will never run any libuv code on that thread ever again, so it is basically just use-after-free |
|
Ok, but that seems like a big caveat missing from the documentation, because that's not how pthread works. |
Wasn't sure if we could get away with deleting the `uv_thread_detach`, but apparently we can. On Windows, it's definitely unsafe to keep using the thread handle after closing it. POSIX is a little less clear about what you're allowed to do with a `pthread_t` after detaching it, but the GC threads never exit normally anyway. Fixes #60042. (cherry picked from commit d8b5662)
This seems like an important caveat, but was not documented. Ref JuliaLang/julia#60056 (comment)
Wasn't sure if we could get away with deleting the `uv_thread_detach`, but apparently we can. On Windows, it's definitely unsafe to keep using the thread handle after closing it. POSIX is a little less clear about what you're allowed to do with a `pthread_t` after detaching it, but the GC threads never exit normally anyway. Fixes #60042. (cherry picked from commit d8b5662)
Wasn't sure if we could get away with deleting the
uv_thread_detach, butapparently we can. On Windows, it's definitely unsafe to keep using the thread
handle after closing it. POSIX is a little less clear about what you're allowed
to do with a
pthread_tafter detaching it, but the GC threads never exitnormally anyway.
Fixes #60042.