Allow the Zig SDK to return arbitrarily big responses #218
Labels
🐛 bug
Something isn't working
👋 good first issue
Good for newcomers
🛟 help wanted
Extra attention is needed
🔨 sdks
Issues related to language SDKs
Comments
ereslibre
added
🐛 bug
|
Hi there, great project! Is it okay if I take this on, and also make some additional updates to the Zig SDK and examples? In addition to solving this issue, I'd like to improve memory management (allow user to provide their own allocator, to perform cleanup after writing response to stdout, etc.), update the SDK and examples to use the Zig package manager (in Zig 0.12.0), and fix zig fmt issues in the SDK/example code as of Zig 0.12 (I think zig fmt was more lenient when the wws Zig SDK was initially written). |
|
@sea-grass would be really happy to see this! Happy to help/review! :) |
|
Great, thanks @voigt. I'll get a PR going within the next few days and tag you as a reviewer so we can continue the discussion there! |
sea-grass
added a commit
to sea-grass/wasm-workers-server
that referenced
this issue
Feb 9, 2024
This commit introduces `kits/zig/wws`, with the intention of replacing `kits/zig/worker`. The design of the new SDK improves upon the previous one by exposing utilities for parsing wws requests and serializing wws responses, to give the user more control over memory while still keeping the SDK easy to use. The name was changed to make it more ergonomic within the Zig ecosystem (the developer will pull in a `wws` dependency to interface with wws, rather than a `worker` dependency).
sea-grass
added a commit
to sea-grass/wasm-workers-server
that referenced
this issue
Feb 23, 2024
This commit introduces `kits/zig/wws`, with the intention of replacing `kits/zig/worker`. The design of the new SDK improves upon the previous one by exposing utilities for parsing wws requests and serializing wws responses, to give the user more control over memory while still keeping the SDK easy to use. The name was changed to make it more ergonomic within the Zig ecosystem (the developer will pull in a `wws` dependency to interface with wws, rather than a `worker` dependency).
This was referenced Jun 2, 2024
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
At this time, the Zig SDK contains some hardcoded values when preparing the response object for Wasm Workers Server.
We should be able to return arbitrarily big responses from a Zig worker, and so, the Zig SDK should use allocation in order to prepare these responses, regardless of how big the response is.
Reproduction steps
Expected behavior
An answer is produced normally, and returned by Wasm Workers Server back to the user.
Additional context
No response
The text was updated successfully, but these errors were encountered: