hniksic
Consistent drop behaviour
Am I correct to say that it's difficult to prevent this from panicking when the SendRC is being dropped as the drop could be initiated from any thread ?!?
I'm struggling to find a good pattern to ensure that the drop thread has ownership of the SendRC when drop is called.
Do you have any thoughts on this ?
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.
Thanks for chasing this. I'm trying to work on a specific example. The instances seem to be reducing the more I simplify my program so there is a significant chance that I was just being silly. You can close the issue for now if you want while I investigate.
On Tue, 25 Apr 2023 at 08:21, Hrvoje Nikšić @.***> wrote:
@gbemiga-viewserver https://github.com/gbemiga-viewserver Any news on this?
— Reply to this email directly, view it on GitHub https://github.com/hniksic/sendable/issues/2#issuecomment-1521276900, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXNXCG4QG7WRJNSB4E4VQ7LXC53RLANCNFSM6AAAAAAWKR3G7E . You are receiving this because you were mentioned.Message ID: @.***>
@gbemiga-viewserver Thanks for the update. It's not a problem to leave it open for a while longer.
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.
https://github.com/hniksic/sendable/pull/4
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.