[Python-Dev] Const access to CPython objects outside of GIL?
tim.peters at gmail.com
Tue Jul 17 12:45:40 EDT 2018
> > Same as the docs, I use "Python object" to mean a pointer to PyObject.
> that sense, a Py_buffer is no more a "Python object" than, e.g,, is a
> > Py_ssize_t.
> 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
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
> 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
> > 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev