Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Extract variable api from ScriptSession, let ScriptSession guard reads #4970
Extract variable api from ScriptSession, let ScriptSession guard reads #4970
Changes from 19 commits
afcddf7
4e2beee
7041746
06ce7f0
7b57fa2
5a1a7cf
d309e35
8b7c820
bd2abcc
8f8102e
4efb27e
c049476
ff6a3ba
deb0a77
c5c1ce7
42ba9be
0b6caa8
d3f0472
e3a0583
cb8646d
abb9dcb
25e4da7
7843871
d2208c3
7598e14
668596d
1e32a0e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Is this true, given that we've enclosing with
ensureGil
?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.
Technically no, the GIL doesn't guarantee us practically anything even if this was one call instead of two -
__setitem__
is just a function that could be redefined in python in a way that lets it drop the gil while invoking it...Practically, we hope that it continued to be kind to us.
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.
Should we be unwrapping
prev
?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.
No, we require callers to invoke unwrap if they want it unwrapped, we don't do it for them - this is consistent with other calls.
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 want to make sure I understand this, let's discuss.
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.
Call
ScriptSessionQueryScope.putParam("foo", somePyObjectInstance)
, and then callsame = readParamValue("foo")
to get it back - the PyObject instances are pointing at the "same" python object, butsame == somePyObjectInstance
is false - they are separate java object instances, and contain separate borrowed pointers into py/c.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's the solution? Is @jmao-denver aware?
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.
There isn't a great solution in general, except to cleanly close PyObject basically everywhere - java gc is required to mop up all the unclosed PyObject. This is wrong in enough places in DHC that it isn't worth dedicating effort to it here.
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.
Since the only things we intend to manage are things we already hold strongly, maybe we should actually use
enforceStrongReachability=true
. That results in a simpler/cleaner implementation of reference tracking. On the other hand, if we expect query scopes to be leaked (as in garbage), that may not be what we want.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.
This question could now apply to ScriptSessionQueryScope, do you still want to consider it?
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.
Do we need a lock on the QueryScope to make this safe?
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.
To make the unwrapping safe? At least not for the implementation (only python) we have today, no.
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.
No, to make the
readParamValue
results be consistent withgetParamNames
. Otherwise, you could have aMissingVariableException
due to concurrent mutation of theQueryScope
.Feels like a missing method to get values, to be honest.