[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