-
Notifications
You must be signed in to change notification settings - Fork 161
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
How can I have []byte array in a struct that is passed as my Context #44
Comments
Unfortunately, cgo has some runtime constraints about pointers passed to C. Everything is explained here https://tip.golang.org/cmd/cgo/#hdr-Passing_pointers. If you share your exact usecase, maybe I can help? |
Hi, I think I'm running into a similar issue as the reporter. At a high level, I'm trying to write a wrapper that will use go-ext-wasm to wrap a wasm module generated in rust via wasm-bindgen. Modules produced with wasm-bindgen require some external implementation of a heap, so that needs to be passed around as context data to the import implementations, but can't be done because of the pointer passing problem. |
To add to the above, wasm-bindgen module imports might also need to call back into the instance itself in order to allocate slices of the module memory, for example. So the context data would also need to include a reference to the module instance itself, so that the implemented imports can call back into the instance. |
Can you give an example so that I could replicate your issue please? |
I think it's as simple as doing:
which results in:
If there isn't a way to include the original instance in the context data somewhere (whether directly or as part of a larger structure), there isn't a way to call its exports from within one of its imports. |
Sorry, I don't understand. |
For example, wasm-bindgen expects an import with the following signature:
The implementation of this function is expected to allocate memory for the JSON serialization of a heap object. wasm-bindgen exports a function called
for the current instance. So basically you need access to the current instance from within your implementation of
But that leads us to the problem above where cgo prevents passing the instance pointer to C. |
The safe way of "passing" Go objects to cgo is to have a global array of Go objects and pass the index to cgo. A fast but unsafe way is to somehow obfuscate the pointer at cgo boundaries, for example by bit-flipping. You need to make sure the pointer is kept somewhere else so that it won't be collected by the GC too early. |
Thanks, I suspected this was the case and was about to give it a try. I'm still hoping it's avoidable via some other approach but I guess those are the limitations we're dealing with. |
…for user data Previously an unsafe.Pointer to user data was passed across the CGo FFI which resulted in a panic if the user data included any other Go pointers. This commit adds a global ctxData registry assigns a unique int id to each instance that calls SetContextData. This id is stored in the actual instance context data that crosses the CGo FFI and is used to look up the actual user data. A sync.RWMutex is used to synchronize access to the ctxData map. BREAKING CHANGE: This changes the API for Instance.SetContextData and InstanceContext.Data to accept and return an interface{} instead of an unsafe.Pointer. re wasmerio#44
…for user data Previously an unsafe.Pointer to user data was passed across the CGo FFI which resulted in a panic if the user data included any other Go pointers. This commit adds a global ctxData registry assigns a unique int id to each instance that calls SetContextData. This id is stored in the actual instance context data that crosses the CGo FFI and is used to look up the actual user data. A sync.RWMutex is used to synchronize access to the ctxData map. BREAKING CHANGE: This changes the API for Instance.SetContextData and InstanceContext.Data to accept and return an interface{} instead of an unsafe.Pointer. re wasmerio#44
…for user data Previously an unsafe.Pointer to user data was passed across the CGo FFI which resulted in a panic if the user data included any other Go pointers. This commit adds a global ctxData registry assigns a unique int id to each instance that calls SetContextData. This id is stored in the actual instance context data that crosses the CGo FFI and is used to look up the actual user data. A sync.RWMutex is used to synchronize access to the ctxData map. BREAKING CHANGE: This changes the API for Instance.SetContextData and InstanceContext.Data to accept and return an interface{} instead of an unsafe.Pointer. re wasmerio#44
…for user data Previously an unsafe.Pointer to user data was passed across the CGo FFI which resulted in a panic if the user data included any other Go pointers. This commit adds a global ctxData registry assigns a unique int id to each instance that calls SetContextData. This id is stored in the actual instance context data that crosses the CGo FFI and is used to look up the actual user data. A sync.RWMutex is used to synchronize access to the ctxData map. BREAKING CHANGE: This changes the API for Instance.SetContextData and InstanceContext.Data to accept and return an interface{} instead of an unsafe.Pointer. re wasmerio#44
…for user data Previously an unsafe.Pointer to user data was passed across the CGo FFI which resulted in a panic if the user data included any other Go pointers. This commit adds a global ctxData registry and assigns a unique int id to each Instance that calls SetContextData. This id is stored in the actual C Instance Context Data that crosses the CGo FFI and is used to look up the actual user data. A sync.RWMutex is used to synchronize access to the ctxData map. BREAKING CHANGE: This changes the API for Instance.SetContextData and InstanceContext.Data to accept and return an interface{} instead of an unsafe.Pointer. re wasmerio#44
Previously the given unsafe.Pointer to user data was passed directly across the CGo FFI resulting in a panic for any reference types or types that included any reference types or other Go pointers. This commit avoids a panic by casting the unsafe.Pointer to a uintptr, which is not analyzed by the runtime. In order for compatability with the existing CGo API and bridge code, which expects (void*), a *uintptr is passed. The memory for the user provided unsafe.Pointer and the *uintptr is cached in the instance to protect it from garbage collection. The tests are expanded to ensure that reference types do not cause panics. re wasmerio#44 wasmerio#83
Can you try with the latest version of |
Previously an uintptr to user data was passed across the CGo FFI which would become invalid if any stack frame occurred. This commit avoids this by never passing any pointers across the CGo FFI. A registry map is used instead to keep Go data on the Go side, and only an int index into the map is passed across to the C side. fix wasmerio#93 re wasmerio#44 wasmerio#85 wasmerio#83
Closing the issue. Please re-open if #85 doesn't solve your issue. Thanks! |
Summary
I need to pass some byte[] array in addition to a few other values as my Context data. The unsafe Pointer thing with CGO seems to limit passing pointers with things other that value types.
Do you know of a workaround to allow passing more complex context object around.
The text was updated successfully, but these errors were encountered: