-
Notifications
You must be signed in to change notification settings - Fork 788
Mitigate deadlock on DLL unload #16416
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
base: main
Are you sure you want to change the base?
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/16416
Note: Links to docs will display an error until the docs builds have been completed. ❗ 1 Active SEVsThere are 1 currently active SEVs. If your PR is affected, please view them below: ❌ 2 New Failures, 1 Unrelated FailureAs of commit 2d43467 with merge base daf93a1 ( NEW FAILURES - The following jobs have failed:
UNSTABLE - The following job is marked as unstable, possibly due to flakiness on trunk:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
|
@felixweilbach has exported this pull request. If you are a Meta employee, you can view the originating Diff in D89889628. |
This PR needs a
|
Summary: ThreadPool gets stored in a static variable here extension/threadpool/threadpool.cpp:146 This means the destructor of ThreadPool will be run when the process exits or a DLL containing this code unloads. While working with ExecuTorch I experienced a deadlock during unloading our DLL (which contained ExecuTorch) at runtime. This was caused by the pthreadpool_destroy function pthreadpool/src/windows.c:366 waiting forever on the worker threads. Why this is happening exactly is unclear to me. It is likely a race condition inside Windows Parallel Loader (https://blogs.blackberry.com/en/2017/10/windows-10-parallel-loading-breakdown) as I could see its functions in the stack trace of the stuck worker threads after they returned from their main function. The issue was mitigated on my side by calling `executorch::extension::threadpool::get_threadpool()->_unsafe_reset_threadpool(0);` before unloading the DLL. This is just a workaround. I think a proper fix would be to rework the ThreadPool singleton and allow for explicit termination of it. Differential Revision: D89889628
29e330c to
2d43467
Compare
kimishpatel
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review automatically exported from Phabricator review in Meta.
Summary:
ThreadPool gets stored in a static variable here extension/threadpool/threadpool.cpp:146
This means the destructor of ThreadPool will be run when the process exits or a DLL containing this code unloads.
While working with ExecuTorch I experienced a deadlock during unloading our DLL (which contained ExecuTorch) at runtime. This was caused by the pthreadpool_destroy function pthreadpool/src/windows.c:366 waiting forever on the worker threads.
Why this is happening exactly is unclear to me. It is likely a race condition inside Windows Parallel Loader (https://blogs.blackberry.com/en/2017/10/windows-10-parallel-loading-breakdown) as I could see its functions in the stack trace of the stuck worker threads after they returned from their main function.
The issue was mitigated on my side by calling
executorch::extension::threadpool::get_threadpool()->_unsafe_reset_threadpool(0);before unloading the DLL.This is just a workaround. I think a proper fix would be to rework the ThreadPool singleton and allow for explicit termination of it.
Differential Revision: D89889628