[Python-Dev] Const access to CPython objects outside of GIL?

[Tim Peters]

[Tim]

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

> that sense, a Py_buffer is no more a "Python object" than, e.g,, is a
> > Py_ssize_t.
>

[Antoine

> Yes, and the payload of an int object is not a "Python object".
> The OP mentioned PyInt_AS_LONG 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>