On Tue, 17 Jul 2018 10:59:02 -0500 Tim Peters <tim.peters at gmail.com> wrote: > > 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. 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. > 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". 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 :-) Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4