-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
GH-38676: [Python] Fix potential deadlock when CSV reading errors out #38713
Conversation
@github-actions crossbow submit -g python -g wheel |
This comment was marked as outdated.
This comment was marked as outdated.
@github-actions crossbow submit -g python -g wheel |
Revision: 01cbb5e Submitted crossbow builds: ursacomputing/crossbow @ actions-296d519c27 |
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.
LGTM, modulo one concern where I'm not totally confident of GIL dynamics
|
||
/// \brief A std::shared_ptr<T, ...> subclass that releases the GIL when destroying T | ||
template <typename... Ts> | ||
using SharedPtrNoGIL = SmartPtrNoGIL<std::shared_ptr, Ts...>; |
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.
What if the no GIL smart pointer wraps an object which must call into python as part of its destruction? (For example a dataset which wraps a python file system.) I think that this will be fine since such a call would acquire the GIL at the call site
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.
I think that this will be fine since such a call would acquire the GIL at the call site
Yes, it would.
After merging your PR, Conbench analyzed the 5 benchmarking runs that have been run so far on merge-commit d076c69. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 2 possible false positives for unstable benchmarks that are known to sometimes produce them. |
…#38713) ### Rationale for this change A deadlock can happen in a C++ destructor in the following case: * the C++ destructor is called from Python, holding the GIL * the C++ destructor waits for a threaded task to finish * the threaded task has invoked some Python code which is waiting to acquire the GIL ### What changes are included in this PR? To reliably present such a deadlock, introduce `std::shared_ptr` and `std::unique_ptr` wrappers that release the GIL when deallocating the embedded pointer. ### Are these changes tested? Yes. ### Are there any user-facing changes? No. * Closes: #38676 Authored-by: Antoine Pitrou <[email protected]> Signed-off-by: Antoine Pitrou <[email protected]>
…rs out (apache#38713) ### Rationale for this change A deadlock can happen in a C++ destructor in the following case: * the C++ destructor is called from Python, holding the GIL * the C++ destructor waits for a threaded task to finish * the threaded task has invoked some Python code which is waiting to acquire the GIL ### What changes are included in this PR? To reliably present such a deadlock, introduce `std::shared_ptr` and `std::unique_ptr` wrappers that release the GIL when deallocating the embedded pointer. ### Are these changes tested? Yes. ### Are there any user-facing changes? No. * Closes: apache#38676 Authored-by: Antoine Pitrou <[email protected]> Signed-off-by: Antoine Pitrou <[email protected]>
Rationale for this change
A deadlock can happen in a C++ destructor in the following case:
What changes are included in this PR?
To reliably present such a deadlock, introduce
std::shared_ptr
andstd::unique_ptr
wrappers that release the GIL when deallocating the embedded pointer.Are these changes tested?
Yes.
Are there any user-facing changes?
No.