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