Op 18 jul. 2018 om 08:02 heeft Barry <ba...@barrys-emacs.org> het volgende geschreven:
> > >>> 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. > Some past attempts at getting rid of the GIL used atomic inc/dec, and that resulted in bad performance because these instructions aren’t cheap. My gut feeling is that you’d have to get rid of refcounts to get high performance when getting rid of the GIL in a single interpreter, which would almost certainly result in breaking the C API. Ronald > 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/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
