>> On 17 Jul 2018, at 21:00, Eric Snow <ericsnowcurren...@gmail.com> wrote: >> >> On Tue, Jul 17, 2018 at 1:44 PM Barry <ba...@barrys-emacs.org> wrote: >> The decrement itself is not the problem, that can be made thread safe. > > Yeah, by using the GIL. <wink> Otherwise, please elaborate. My > understanding is that if the decrement itself were not the problem > then we'd have gotten rid of the GIL already.
All processors have thread safe ways to inc and dec and test, integers without holding a lock. That is the mechanism that locks themselves are built out of. You can use that to avoid holding the GIL until the ref count reaches 0. In c++ they built it into the language with std::atomic_int, you would have to find the way to do this C, i don’t have an answer at my finger tips for C. Barry > >> Do you mean that once the ref reaches 0 you have to make the delete happen >> on the original interpreter? > > Yep. For one thing, GC can trigger __del__, which can do anything, > including modifying other objects from the original interpreter (incl. > decref'ing them). __del__ should be run under the original > interpreter. For another thing, during GC containers often decref > their items. Also, separating the GIL between interpreters may mean > we'll need an allocator per interpreter. In that case the > deallocation must happen relative to the interpreter where the object > was allocated. > > -eric > _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
