This repository was archived by the owner on Apr 25, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 74
current frame memory access for js callees #67
Comments
That seems unrelated to this proposal, which notably does not have any connection to memory objects at all. I suggest creating an issue on the design repo. (That said, we could provide first-class references to memory objects, the same way we already provide function references. What we cannot do, however, is giving external access to memory that is not exported or otherwise handed out explicitly. We also cannot give access to exports before the start function has terminated, since that would break the initialisation semantics of a module.) |
rossberg
pushed a commit
that referenced
this issue
Feb 24, 2021
* Initial test generation code * Cleanup * Parameterize * Cleanup * Rename * More tests * Table copy * table.init * More tests * More memory.init tests * table.copy * data.drop and elem.drop * Updates for the reference interpreter * Partial memory.fill * Comment out test for reference interpreter * Partial OOB for memory_init * Partial table.init * Partial OOB for table.copy * Some binary tests * Uncontroversial updates * Test suite updates after discussion with binji * Binary tests for elem segments * Fix test bug, update comments
rossberg
pushed a commit
that referenced
this issue
Feb 24, 2021
rossberg
added a commit
that referenced
this issue
Sep 20, 2022
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It's not possible for JS callees to gain access to S.mems[0] without it being explicitly exported under a prenegotiated name. This means that it's not possible to work with functions that require memory access within the wasm start function, and it makes it impossible to import a function with the esm proposal that can access the memory.
This seems like a super important step to consider with the design of memory moving forward. I've seen it be a design blocker at least once within WASI (WebAssembly/WASI#19), and I've had to work around it in various other projects I've worked on.
Two ideas I have had are being able to pass memories as function arguments, and having a
WebAssembly.currentMemories
getter of some sort.The text was updated successfully, but these errors were encountered: