Add a memory.grow handler in the RT
#2755
Conversation
This handler can be used with an import for users not using ESM bindings to recreate views into memory only when necessary.
If the test is supposed to compile, but compilation fails instead, there's no point in diffing fixtures (unless you like a wall of red in your terminal). It also turns out that execution never reaches the diffing section, since writing the non-existent debug Wasm binary fails.
CountBleck
force-pushed
the
memory-grow-handler
branch
from
afd90e7 to
de40b29
Compare
|
User can directly call |
|
Good point, although I thought that would be a niche case in comparison to the RT growing memory. Do you think a handler can/should be integrated with ESM/raw bindings to reduce the use of |
I'm not sure what is a better solution. Previously, we used similar approach (without try-catch + views) and that was may be a little less code but slower. I would do a some simple PoC and bench this first |
There was a problem hiding this comment.
Do you think it is more convenient for developer if we have a function memory_grow which will call memory.grow. Then developer can replace this function just like replacing trace.
It can give more freedom to hook memory grow. They can hook before and after memory grow.
Honestly the only use case I'm targeting is handling views of the Wasm memory being detached on I want to expand that into something that works with ESM bindings as well. I don't see the point in widening it to anything more general. Therefore, it's probably better to scrap what I have in this PR right now and figure out something that works for detecting grow events in at least ESM bindings. |
Changes proposed in this pull request:
⯈ Add an optional handler for calls to
memory.grow()in the RT.⯈ Unrelatedly, skip fixture comparisons in tests if compiling them failed.
The question remains whether this could somehow be used within ESM bindings.