[Python-Dev] Const access to CPython objects outside of GIL? (original) (raw)

Tim Peters tim.peters at gmail.com
Tue Jul 17 12:45:40 EDT 2018

[Tim]

> Same as the docs, I use "Python object" to mean a pointer to PyObject. In

that sense, a Pybuffer is no more a "Python object" than, e.g,, is a > Pyssizet.

[Antoine

Yes, and the payload of an int object is not a "Python object". The OP mentioned PyIntASLONG as an example, so clearly the question was broader than you're painting it to be.

Ah, but I don't know that. The docs carve out no exception for the PyInt_AS_LONG API function, and since that doesn't appear to exist in Python 3 anymore (the only Python source I have on my box right now) I couldn't stare at the implementation to guess. Staring at implementations is the only way to guess.

If they want to muck with the buf member without the GIL, then if they > care about races among multiple threads mucking with buf, they'll have to > supply their own mutual exclusion mechanism.

Define "muck with".

Precisely my point: your unqualified "safe" is missing all the qualifications needed to spell out when it's actually safe. "safe" is a subtler question than you're painting it to be ;-)

As long as you're reading the memory area(s)

pointed to by the Py_buffer object, you're fine. If you plan to write

to that memory, obviously you'll need to make sure the various threads don't overwrite each other, i.e. distribute the work carefully.

But that's a normal provision for multi-threaded algorithms, not a Python-specific restriction. I'm assuming someone asking a question about multi-threaded access to CPython objects already knows all this :-)

While I don't assume that. Looking it up, if they stared at

#define PyInt_AS_LONG <https://help.autodesk.com/cloudhelp/2018/ENU/MotionBuilder-SDK/cpp_ref/intobject_8h.html#a225d34d2e970c9942b56910a20c29277> (op) (((PyIntObject <https://help.autodesk.com/cloudhelp/2018/ENU/MotionBuilder-SDK/cpp_ref/struct_py_int_object.html> *)(op))->ob_ival) in Python 2 and had to ask whether it was safe to invoke without the GIL, then a more plausible assumption is they're going more by poke-&-hope than by reasoning. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180717/100acb76/attachment.html>

More information about the Python-Dev mailing list