Add ffi support for JS null and switch to wasm-gc struct for error signaling#5719
Conversation
Instead, we use wasm-gc except on safari iOS. On iOS, use a JS object and a JS trampoline.
ryanking13
left a comment
There was a problem hiding this comment.
I am curious what's the benefit of using actual null instead of JS null (not opposed to this PR, just curious).
|
The point is to allow JS APIs that distinguish between |
|
@ryanking13 I changed a bunch of stuff since your first review so if you could rereview and let me know what you think now. There still seem to be some crashes to iron out but I think they are minor find-and-replace style changes. |
ryanking13
left a comment
There was a problem hiding this comment.
Thanks. There is a build failure, but codewise looks fine to me.
So not everything is broken =) |
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
I separated this from pyodide#5719 to keep the diff from getting too large
I separated this from pyodide#5719 to keep the diff from getting too large
I separated this from pyodide#5719 to keep the diff from getting too large
I separated this from #5719 to keep the diff from getting too large.
We need JS null to represent actual null and not an error. Instead, we use wasm-gc except on safari iOS
where wasm-gc is broken or on old runtimes where wasm-gc support is missing. If we can't use wasm-gc,
we use a JS object and a JS trampoline. There is maybe a 3-4% performance hit associated with
this fallback compared to before this PR. Using wasm-gc to signal errors leads to no measured performance
change.
Resolves #3968.
Left to a followup to keep diff down: