github-actions[bot] commented on code in PR #40822:
URL: https://github.com/apache/beam/pull/40822#discussion_r4381315123
##########
sdks/python/apache_beam/utils/multi_process_shared.py:
##########
@@ -150,8 +152,22 @@ def release(self, proxy):
def unsafe_hard_delete(self):
with self.lock:
if self.initialied:
+ obj = self.obj
del self.obj
self.initialied = False
+ # When hard-deleting in a spawned server process that exits via
+ # os._exit(0), an in-flight RPC thread (e.g. a timed-out call) may
+ # still hold a stack reference to `obj`, preventing CPython from
+ # invoking `obj.__del__()` before `os._exit(0)`.
+ if (self._hard_delete_callback is not None and
+ sys.getrefcount(obj) > 2 and hasattr(type(obj), '__del__')):
Review Comment:
**🟡 Medium**: `sys.getrefcount(obj) > 2` relies on CPython incrementing the
reference count both for the local variable `obj` and for passing `obj` as an
argument to `sys.getrefcount()`. In Python 3.14+, the compiler emits
`LOAD_FAST_BORROW` for local variable loads, which does not increment the
reference count when pushing `obj` onto the stack for `sys.getrefcount(obj)`.
As a result:
- When only one in-flight thread holds a reference to `obj` (total actual
references = 2: `obj` local + the in-flight frame), `sys.getrefcount(obj)`
returns `2` on Python 3.14+, so `> 2` evaluates to `False` and `__del__` will
be skipped before `os._exit(0)`.
- Conversely, if `del obj` fails to drop the refcount to zero (and
`os._exit(0)` is about to terminate the process anyway when
`self._hard_delete_callback is not None`), we can avoid `sys.getrefcount`
altogether by checking a `weakref` after `del obj` or invoking
`type(obj).__del__(obj)` before `self._hard_delete_callback()` exits the
process.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
