On Wed, Jun 17, 2020 at 5:56 AM Nick Coghlan <ncogh...@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.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7MR4MJDTFQIEEMY6WQ2IE4EYFYU6PPKJ/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to