Consistent drop behaviour about sendable HOT 6 OPEN

Hi, can you provide a more detailed description of the issue you are having?

In particular, I'm not sure how the drop could be initiated from any thread. SendRc is supposed to exist in one thread, unless you explicitly move it to a different thread, in which case you are responsible to park it before moving and unpark it after.

from sendable.

@gbemiga-viewserver Any news on this?

from sendable.

from sendable.

@gbemiga-viewserver Thanks for the update. It's not a problem to leave it open for a while longer.

from sendable.

Thank you for so patiently leaving this issue open. I have created a PR to demonstrate my issue. I am quite open to this not being an issue at all and in fact, being an unsupported usage pattern. The issue that I have with my application is that I cannot guarantee that the thread that invokes the drop has ownership of the SendRc so I get really strange failures as in the test I have added. Can you tell me what to do or how to think :) To prevent issues like this. Thanks.

#4

from sendable.

Thanks for providing a concrete example. Indeed, this usage pattern is not only unsupported, but SendRc is actually designed to detect and prevent it. You're required to move all the SendRc's to another thread, and your code doesn't do that, it r1 and r2 to two different threads.

It doesn't matter that the only thing that happens to r1 is dropping it. If such a drop were allowed, it would allow a data race (undefined behavior in Rust) simply by cloning or dropping r2 in the first thread. This is because clone() and drop() modify the reference count without explicit synchronization.

Note that even if SendRc used atomic reference counts (which would eliminate much of its performance benefits), panic would still be possible if the "wrong" thread happened to be the one to reach refcount==0.

from sendable.