-
Notifications
You must be signed in to change notification settings - Fork 208
Updates KernelAttributes to avoid possible dangling handles. #957
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
|
||
def _get_cached_attribute(self, device_id: int, attribute: driver.CUfunction_attribute) -> int: | ||
"""Helper function to get a cached attribute or fetch and cache it if not present.""" | ||
if device_id in self._cache and attribute in self._cache[device_id]: |
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 also see an opportunity to simplify the logic throughout to use pairs as keys:
if (device_id, attribute) in self._cache:
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.
Fixed in 651beb9
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.
Looks good to me.
My suggestion is meant to be a minor by easy optimization.
"""Helper function to get a cached attribute or fetch and cache it if not present.""" | ||
if device_id in self._cache and attribute in self._cache[device_id]: | ||
return self._cache[device_id][attribute] | ||
if (device_id, attribute) in self._cache: |
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.
WDYT about
cache_key = (device_id, attribute) # so this tuple doesn't have to be rebuilt
result = self._cache.get(cache_key, cache_key) # the tuple doubles as sentinel; there is only one cache lookup
if result is not cache_key:
return result
then all the way below
self.cache[cache_key] = result
return result
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.
Good suggestion, thanks!
/ok to test 1878c2d |
This comment has been minimized.
This comment has been minimized.
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.
Looks great to me!
Sorry I missed the full context: How did you discover the bug fixed in this PR? Is there a reasonably easy way to add a test that would have created a dangling handle? — I wouldn't spend more than 10 minutes on that.
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.
Question: Is it possible to write a unit test that exercises the weakref?
Leo asked me to bundle the attributes for IPC-enabled mempools and pointed to this as a reference implementation. I noticed this issue by inspection when reading the code. There is an example test called Maybe to be more specific, it was this code that set off the alarm bells:
When an object ( |
I looked into this and I think it would be difficult right now. The reference management is a bit of a mess. E.g., there is a reference cycle between Kernel, which refers to a Module, which refers to its Kernels. That makes it difficult to accurately delete Kernels as we'd need for this test. If we cleaned up the references overall it would be easier. |
|
Sorry I did not have a chance to read this PR. It is fine. But there was not bug, and this PR is not a bug fix. In case it is not clear, this was implemented by design. |
Previously a
KernelAttributes
bundle held a reference to an internal handle from aKernel
object. This change introduces a weak reference to ensure that a dangling handle is never used. Testing shows no statistically significant change to property access times.