Object is unsendable, but is being dropped on another thread

[davidbrochart]

After reading #3688 and #3689, I'm still not sure what to do with an unsendable pyclass. When it is garbage collected from a different thread than the thread it was created in, I get the RuntimeError: ... unsendable, but is being dropped on another thread.
Does it mean that my object is not dropped, and that it would lead to memory leaks?

[davidbrochart]

Oh maybe I didn't get it right: when the object is being garbage collected from a different thread, it will actually not be, and then it will be garbage collected later in its home thread?

[birkenfeld]

The check you see comes from the tp_dealloc of that object. At that point, the Python part of the object is being garbage collected. (The error is merely printed to stderr because that method may not fail.) The Rust part (the contents of the pyclass struct) are not dropped and will leak, if they have a nontrivial Drop.

[davidbrochart]

So is my only option to manually call gc.collect() in the right thread, to make sure my object is not garbage collected in another thread?

[birkenfeld]

I guess that depends. Is your object GC aware (has __traverse__ and __clear__ methods)? If not, it will not be touched by the garbage collector and only be able to be destroyed when its reference count goes to zero. This is relatively deterministic, so you should be able to achieve that in the correct thread. gc.collect() will not do anything here.

If it is GC aware, and takes part in reference cycles that the garbage collector is required to trace, I guess the only way is to keep it alive using a known reference and when you want to destroy it, delete that reference and call gc.collect() from the correct thread.

(This info is only valid for CPython, PyPy doesn't do ref-counting and always uses a non-deterministic GC as far as I know.)

[birkenfeld]

In general though, it might be worth checking if it's not easier to make the pyclass satisfy impl Send instead.