You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The multiprocessing library allows finalizers to be attached to specific objects, so as to release system resources. These finalizers may have non-trivial code that rely on and alter global state.
Unfortunately, since mainline code can be interrupted at any time by the GC, there can be rare reentrancy issues with such non-trivial finalizers, such as in gh-109593.
Ideally, we would run such finalizers in a separate thread rather than from inside the GC.
Ok, I gave it a try... but, of course, the problem is that fork wreaks havoc with threads, and of course it's difficult to test multiprocessing (or concurrent.futures) without making a lot of calls to fork.
:-D
pitrou
added a commit
to pitrou/cpython
that referenced
this issue
Oct 7, 2023
Feature or enhancement
Proposal:
The multiprocessing library allows finalizers to be attached to specific objects, so as to release system resources. These finalizers may have non-trivial code that rely on and alter global state.
Unfortunately, since mainline code can be interrupted at any time by the GC, there can be rare reentrancy issues with such non-trivial finalizers, such as in gh-109593.
Ideally, we would run such finalizers in a separate thread rather than from inside the GC.
Note this is related to https://peps.python.org/pep-0556/, but much more focussed and therefore with a higher chance of success.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Linked PRs
The text was updated successfully, but these errors were encountered: