Depends what you mean by caching, but the file packager (tools/file_packager.py) has a caching option in IndexedDB.
On Wed, Apr 3, 2019 at 12:42 AM Tapan Anand <[email protected]> wrote: > Thanks Alon, it worked! > With regards to lazily loading the side_module I am thinking of using > dlopen and before calling dlopen building a way to do synchronous XHR for > the side_module wasm and putting it in the FS object. I will also have to > make sure that I don't fetch the same side_module more than once (caching). > Does there exist a way to do this in the toolchain itself or will I have > to write my own fetching and caching logic? > > On Tuesday, 2 April 2019 02:04:39 UTC+5:30, Alon Zakai wrote: >> >> I think what's going on here is that clock() is implemented in a JS >> library, and EXPORTED_FUNCTIONS doesn't cover those. We've had some ideas >> for how to unify exports, since really the current state is just confusing >> - it shouldn't matter where a function is implemented if you just want to >> export it. But we don't have a good plan to solve this yet. >> >> Meanwhile, -s "DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=['clock']" will include >> it from the JS library, which should work for your use case. >> >> >> >> On Fri, Mar 29, 2019 at 5:17 AM Tapan Anand <[email protected]> >> wrote: >> >>> While trying to use dynamic linking to lazy load "less-used" >>> code/libraries in my code, I encountered an issue where the SIDE_MODULE was >>> not able to access a standard library function. I have built a smaller test >>> case for the same where I try to use the standard library function clock >>> from time.h in the SIDE_MODULE. >>> >>> Here is the code and build files for the same: >>> https://github.com/tapananand/dynLinkPOC You can build it by running >>> command `make all`. Here, the SIDE_MODULE tries to use the clock() function >>> of time.h library but it can't get its implementation from the MAIN_MODULE. >>> >>> On running the dynLink.html file, which loads the generated wasm in a >>> web worker, an error is encountered >>> TypeError: Cannot read property 'apply' of undefined >>> >>> On debugging further this boils down to _clock not being defined on the >>> Module object. >>> On building with MAIN_MODULE=1, it all works fine. So, it seems that >>> _clock is dead code eliminated from the MAIN_MODULE when using >>> MAIN_MODULE=2, although I have added it in the -s EXPORTED_FUNCTIONS list >>> option (as seen in the Makefile) >>> >>> *Is this a known issue or am I doing something wrong here?* >>> >>> Also, I am using loadDynamicLibrary to be able to lazily load the second >>> wasm, but the documentation here >>> <https://github.com/emscripten-core/emscripten/wiki/Linking#hyper-dynamic-linking> >>> mentions, globals might not work fine. I have actually encountered issues >>> when trying to use cout in the side module in this same sample (try >>> uncommenting the cout in doubler.cpp). So, *is there an alternative way >>> to lazily load side module which doesn't have these issues?* >>> >>> Thanks in advance for your help! >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
