On 18 July 2018 at 05:35, Eric Snow <ericsnowcurren...@gmail.com> wrote: > In order to make all this work the missing piece is a mechanism by > which the decref (#3) happens under the original interpreter. At the > moment Emily Morehouse and I are pursuing an approach that extends the > existing ceval "pending call" machinery currently used for handling > signals (see Py_AddPendingCall). The new [*private*] API would work > the same way but on a per-interpreter basis rather than just the main > interpreter. This would allow one interpreter to queue up a decref to > happen later under another interpreter. > > FWIW, this ability to decref an object under a different interpreter > is a blocker right now for a number of things, including supporting > buffers in PEP 554 channels.
Aw, I guess the original idea of just doing an active interpreter context switch in the current thread around the shared object decref operation didn't work out? That's a shame. I'd be curious as to the technical details of what actually failed in that approach, as I would have expected it to at least work, even if the performance might not have been wonderful. (Although thinking about it further now given a per-interpreter locking model, I suspect there could be some wonderful opportunities for cross-interpreter deadlocks that we didn't consider in our initial design sketch...) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
