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/
