[Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

Barry barry at barrys-emacs.org
Wed Jul 18 03:02:38 EDT 2018



>> On 17 Jul 2018, at 21:00, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>> 
>> On Tue, Jul 17, 2018 at 1:44 PM Barry <barry at 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
> 



More information about the Python-ideas mailing list