-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
gh-127065: Make methodcaller thread-safe and re-entrant #127245
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
Closed
Closed
Changes from all commits
Commits
Show all changes
21 commits
Select commit
Hold shift + click to select a range
223d650
Make methodcalled thread-safe
eendebakpt b6d454a
check result of PyMem_Malloc
eendebakpt 4ce1233
enable ft
eendebakpt cf6b79b
fix memory error
eendebakpt 2476ce4
wip
eendebakpt 5ecf876
add tests
eendebakpt 709010d
wip
eendebakpt 6bd2c2e
wip
eendebakpt 8d40552
Merge branch 'main' into methodcaller_ft
eendebakpt c9e3898
wip
eendebakpt 8ef7a04
fix memory error
eendebakpt b4f30d3
skip check on zero size for memcpy
eendebakpt 6d06201
📜🤖 Added by blurb_it.
blurb-it[bot] 56cdc1f
Merge branch 'methodcaller_ft' of github.com:eendebakpt/cpython into …
eendebakpt 440eb0c
Merge branch 'main' into methodcaller_ft
eendebakpt ad66951
review comments
eendebakpt bc3fe2a
review comments
eendebakpt e9a1fa6
Update Modules/_operator.c
eendebakpt 00ab654
Update Modules/_operator.c
eendebakpt 5a7344b
review comments
eendebakpt f9f53fe
Merge branch 'methodcaller_ft' of github.com:eendebakpt/cpython into …
eendebakpt File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1 change: 1 addition & 0 deletions
1
Misc/NEWS.d/next/Library/2024-12-01-22-28-41.gh-issue-127065.tFpRer.rst
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
Make :func:`operator.methodcaller` thread-safe and re-entrant safe. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
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.
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.
The ownership here seems a bit complicated and I think it can be simplified. As I understand it,
vectorcall_kwnames
only exists to ensure that some entries invectorcall_args
stay alive.Instead, I'd suggest:
PyObject *vectorcall_args
a tuple (that holds strong references to its contents as usual)vectorcall_kwnames
_PyTuple_ITEMS
for fast access to the contents of the tuple (formemcpy()
)vectorcall_args
inmethodcaller_traverse
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.
The
vectorcall_kwnames
is needed as an argument forPyObject_VectorcallMethod
inmethodcaller_vectorcall
(https://github.com/python/cpython/blob/main/Modules/_operator.c#L1666), so we cannot get rid of it.The ownership is not too hard I think: the objects in
vectorcall_args
have references borrowed from eithermc->args
or (the keys from)mc->kwds
. I added a comment to clarify this.Making the
vectorcall_args
a tuple is still an option though. It requires a bit more memory and a tiny bit of computation in the initialization. It would be the C equivalent ofvectorcall_args = args + tuple(kwds)
. I'll work it out in a branch to see how it comparesThere 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.
Okay, in that case don't worry about it unless you prefer it as a tuple.
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.
The diff between the two approaches is this:
eendebakpt/cpython@methodcaller_ft...eendebakpt:cpython:methodcaller_ft_v2
What is nice about making
vectorcall_args
a tuple is that if there are no keyword arguments, we can reusemc->args
. It does require more operations in the construction though.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 either approach is fine! My guess is that the vast majority of uses of
methodcaller()
do not use keyword arguments.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.
Running benchmarks shows what is to be expected from the implementations: using a tuple for
vectorcall_args
is a bit slower in initializing, except when there are no keyword arguments (since then we reuse thearg
tuple). Differences are small though.Since using a tuple leads to cleaner code and the majority of uses is without keywords I slightly prefer the tuple approach. I will open a new PR for it.