JS / WASM interface questions

37 views
Skip to first unread message

キャロウ マーク

unread,
Jul 19, 2020, 7:32:58 PM7/19/20
to emscripten-discuss
Let me try asking these again with a different subject line in the hope of attracting answers.

  1. Is it possible for 2 separately compiled .wasm packages to use the same HEAP8, possibly by not modularizing them? This would be to avoid data copies between the packages.
  2. If using webidl_binder, copying data from JS to a WASM module requires something like:

       var wasmInBuffer = Module._malloc(myDataLength);
               Module.HEAPU8.set(myData, wasmInBuffer);
               Module.function(wasmInBuffer);
               Module._free(wasmInBuffer);

           Is it possible to add this JS to Module so instead of the module users having to do malloc & free it is internal to Module?

Hoping for some answers.

    -Mark

signature.asc

Hostile Fork

unread,
Jul 20, 2020, 11:31:23 PM7/20/20
to emscripten-discuss
  1. Is it possible for 2 separately compiled .wasm packages to use the same HEAP8, possibly by not modularizing them? This would be to avoid data copies between the packages.
I'm also interested in having a core of a system that pulls in "DLLs" later that can access the same HEAP8.

It seems that there is some support for DLLs/.so ... which means being able to share pointers with the code that loaded them (hence same heap):


This makes use of something called "SIDE_MODULE" which is a more basic form of compilation that doesn't include system libraries, and you attach it to some heap that's already around, or that you create.  You can also use this to make more bare-bones WASM code that doesn't have all of emscripten's overhead, a (possibly outdated) demo is here:

 
The page points out a problem I'd wondered about trying to use a SIDE_MODULE:

"The one tricky aspect to this design is that a side module might need a system library that the main doesn't know about."

So it looks like you might wind up having to make a fairly "fat" main module if you want to cover the contingencies of arbitrary SIDE_MODULEs that came along later.
Reply all
Reply to author
Forward
0 new messages