-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
is it possible to return handlers to complex go structs #7
Comments
In the long run, I plan to split up a bunch of coupled components in this repository, including exposing different ABI interfaces for selection, using interfaces for structure conversion and allowing users to implement them manually, etc. |
Manuall is totally fine, the problem I ran into is that in the rust-side of things I couldn't express "this is a pointer to unknown" as any approach I tried told me parameterized type are a no-no |
I have the same exact usecase and I can't find a way to express pointers in the FFI boundary. I skimmed the blog post about the library and it felt like this is expected because it explicitly mentions "...As we cannot control the lifetime of the return value Rust side receives (the upper layers might even store it in a global structure), the copy upon being called by FFI on the Rust side is inevitable; Rust performs the copy after being called, allocating its own memory..." somewhere. Does that mean we can't work with raw pointers in the FFI boundary? Do we need to have owned values or smart pointers in the return values of Go functions? |
Passing pointer as a number is ok now. But passing and managing the object lifetime behind the pointer are 2 different things. Make a smart pointer and map it to different languages are good, at lease for Rust/C++. However, golang seems haven't provide a destructor ability which can be automatically called when the object is going to be released. There are another totally different way to do that: since I also provide a shared-memory mode, doing it based on communication will be very easy. Current definition is like:
However, now the CGO mode and shared-memory mode are compatiable with each other. If implement it like the former solution, it will only work under shared-memory mode. To make CGO mode also work, we may add another CGO call for each async call that does not copy response instantly. This will make the project more elegant by making some abstraction with the oneway message passing(it can be a CGO call or shm queue message). Do you have any idea about it? Or do you have interest implementing it? :) |
Hi,
I am wondering if and how it is possible to return complex structures (or points to them more likely) as opaque types from calls.
Say I have a client implemented in go and want to initialize it and then return a handler to the client.
I basically want to do something like this:
The text was updated successfully, but these errors were encountered: