[Python-ideas] Ideas towards GIL removal

[Greg Ewing]

Brett Cannon wrote:

> In reality this is true, but obviously not technically true.  You could 
> delete a class if you really wanted to.  But obviously it rarely happens.

And if it does, the worst that will happen is that
the original version will hang around, tying up a
small amount of memory.

> I wonder what the overhead is going to be.  If for every INCREF or 
> DECREF you have to check that an object is immortal or whether it is a 
> thread-owned object is going to incur at least an 'if' check, if not 
> more.

Clearly, there will be a small increase in overhead.
But it may be worth it if it avoids the need for
a rather expensive lock/unlock. It was pointed out
earlier that, even using the special instructions
provided by some processors, this can take a great
many times longer than a normal memory access or
two.

> And for the second idea, adding two more fields to every object might be 
> considered expensive by some in terms of memory.

Again, it's a tradeoff. If it enables removal of
the GIL and massive threading on upcoming multi-
core CPUs, it might be considered worth the cost.
> 
> Also, how would this scenario be handled: object foo is created in 
> thread A ...  is passed to thread B, and then DECREF'ed in thread B as
> the object is no longer needed by anyone.

I'll have to think about that. If a thread gives
away a reference to another thread, it really
needs to be a global reference rather than a
local one. The tricky part is telling when this
happens.

> But if objects start with a global refcount of 1 but a 
> local refcount of 0 and it is DECREF'ed locally then wouldn't that fail 
> for the same reason?

That one's easier -- if the local refcount is 0
on a decref, you need to lock the object and
decrement the global refcount.

--
Greg