-
-
Notifications
You must be signed in to change notification settings - Fork 33.2k
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
Changes from 15 commits
223d650
b6d454a
4ce1233
cf6b79b
2476ce4
5ecf876
709010d
6bd2c2e
8d40552
c9e3898
8ef7a04
b4f30d3
6d06201
56cdc1f
440eb0c
ad66951
bc3fe2a
e9a1fa6
00ab654
5a7344b
f9f53fe
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
Make :func:`operator.methodcaller` thread-safe and re-entrant safe. |
Original file line number | Diff line number | Diff line change | ||||||
---|---|---|---|---|---|---|---|---|
|
@@ -1595,36 +1595,59 @@ static PyType_Spec attrgetter_type_spec = { | |||||||
typedef struct { | ||||||||
PyObject_HEAD | ||||||||
PyObject *name; | ||||||||
PyObject *xargs; // reference to arguments passed in constructor | ||||||||
PyObject *args; | ||||||||
PyObject *kwds; | ||||||||
PyObject **vectorcall_args; /* Borrowed references */ | ||||||||
PyObject *vectorcall_kwnames; | ||||||||
vectorcallfunc vectorcall; | ||||||||
} methodcallerobject; | ||||||||
|
||||||||
#ifndef Py_GIL_DISABLED | ||||||||
|
||||||||
#define _METHODCALLER_MAX_ARGS 8 | ||||||||
|
||||||||
static PyObject * | ||||||||
methodcaller_vectorcall( | ||||||||
methodcallerobject *mc, PyObject *const *args, size_t nargsf, PyObject* kwnames) | ||||||||
|
||||||||
{ | ||||||||
if (!_PyArg_CheckPositional("methodcaller", PyVectorcall_NARGS(nargsf), 1, 1) | ||||||||
|| !_PyArg_NoKwnames("methodcaller", kwnames)) { | ||||||||
return NULL; | ||||||||
} | ||||||||
assert(mc->vectorcall_args != NULL); | ||||||||
|
||||||||
Py_ssize_t number_of_arguments = PyTuple_GET_SIZE(mc->args) + | ||||||||
(mc->vectorcall_kwnames? PyTuple_GET_SIZE(mc->vectorcall_kwnames):0); | ||||||||
eendebakpt marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||||
|
||||||||
PyObject *tmp_args[_METHODCALLER_MAX_ARGS]; | ||||||||
tmp_args[0] = args[0]; | ||||||||
assert(1 + number_of_arguments <= _METHODCALLER_MAX_ARGS); | ||||||||
memcpy(tmp_args + 1, mc->vectorcall_args, sizeof(PyObject *) * number_of_arguments); | ||||||||
|
||||||||
PyObject *result = PyObject_VectorcallMethod( | ||||||||
|
||||||||
mc->name, tmp_args, | ||||||||
(1 + PyTuple_GET_SIZE(mc->args)) | PY_VECTORCALL_ARGUMENTS_OFFSET, | ||||||||
mc->vectorcall_kwnames); | ||||||||
|
||||||||
return result; | ||||||||
} | ||||||||
|
||||||||
static int _methodcaller_initialize_vectorcall(methodcallerobject* mc) | ||||||||
|
static int _methodcaller_initialize_vectorcall(methodcallerobject* mc) | |
static int | |
_methodcaller_initialize_vectorcall(methodcallerobject *mc) |
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.