On Wed, Jun 17, 2020 at 5:56 AM Nick Coghlan <ncoghlan@gmail.com> wrote:

Doing full blown zero-copy ownership transfer of actual Python objects would be more difficult, since the current plan is to have separate memory allocation pools per interpreter to avoid excessive locking overhead, so I don't currently expect to see that any time soon, even if PEP 554 is accepted. Assuming that remains the case, I'd expect multiprocessing to remain the default choice for CPU bound use cases where all the interesting state is held in Python objects (if you're going to have to mess about with a separate heap of shared objects anyway, you may as well also enjoy the benefits of greater process isolation).

So most likely there wouldn't be any way to share something like a bytearray or another buffer interface-compatible type for some time. That's too bad, I was hoping to have shared arrays that I could put a memoryview on in each thread/interpreter and deal with locking if I need to, but I suppose I can work through an extension once the changes stabilize. Packages like NumPy have had their own opaque C types and C-only routines to handle all the big threading outside of Python as a workaround for a long time now.