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

[Barry Scott]

> 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.

Let me try a longer answer. The inc+test and dec+test do not require a
lock if coded correctly. All OS and run times have solved this to provide
locks. All processors provide the instructions that are the building blocks
for lock primitives.

You cannot mutate a mutable python object that is not protected with the GIL as
the change of state involves multiple parts of the object changing.

If you know that an object is immutable then you could only do a check on the
ref count as you will never change the state of the object beyond its ref count.
To access the object you only have to ensure it will not be deleted, which the
ref count guarantees. The delete of the immutable object is then the only job
that the original interpreter must do.

> 
>> 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.

Yep that I understand.

Barry

> 
> -eric
>