You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that passing a reference in a sync call might cause a dangling pointer because the reference on the Go side might be saved, while it could have already been dropped on the Rust side.
Given that the design goal of this crate is to pursue extreme performance, this might be expected. However, I am wondering if synchronous calls should also be considered unsafe, similar to asynchronous calls.
There are 2 responsibites, one is to ensure params not dropped when go executing user's function, and another one is to make sure borrowed parameters not outlive the function.
I think the first one is for rust, so not taking ownership and drop the future is not safe.
The second one is for golang side to obey. Since there's no unsafe marker in golang, users must ensure it by themself. We cannot push this responsibility to rust because golang not having unsafe marker, it is not rust side's job.
Thank you for creating this great crate!
I noticed that passing a reference in a sync call might cause a dangling pointer because the reference on the Go side might be saved, while it could have already been dropped on the Rust side.
Given that the design goal of this crate is to pursue extreme performance, this might be expected. However, I am wondering if synchronous calls should also be considered unsafe, similar to asynchronous calls.
Please have a look or try this simple example:
https://github.com/Heap-Hop/rust2go/tree/unsafe_sync
Heap-Hop@9734b24#diff-8aa8e83ff3b2189fd6397149a7b274f82daede3923191a3d0409f72a2f8bb78fR36
If I missed any mention of similar issues in the documentation, please correct me. Thanks again.
The text was updated successfully, but these errors were encountered: