Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Josiah Carlson wrote:
Certainly, but thread B isn't the owning thread, thread A was the owning thread, and by virtue of decrefing its thread count to zero, acquiring the GIL, and checking the global refcount to make sure that either someone else is responsible for its deallocation (global refcount > 0), or that thread A is responsible for its deallocation (global refcount == 0).
Thread B holding the GIL doesn't help, because the local refcount is not covered by the GIL. Thread A must be able to assume it has total ownership of the local refcount, otherwise there's no benefit in the scheme.
I seem to not be explaining myself well enough. What you describe is precisely what I described earlier. I don't believe we have a disagreement about the execution semantics of threads on an object with a local thread count. I was only mentioning A acquiring the GIL if/when it becomes finished with the object, to determine if the object could be sent to the standard Python deallocation rutines, and/or if thread A should send it (as opposed to thread B in the case if thread B was passed the object and was using it beyond the time that A did). - Josiah