You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current implementation of FS in JS keeps everything in memory. In real world cases users may want to keep their files in persistent storage. Filesystem support in TeaVM already relies on interface, which has implementations (in-memory and WASI), so it's only a matter of providing extra implementations as well as a way to pass compiler the name of desired implementation (TeaVM properties can be used for example).
It's reasonable to have two additional implementations for JS BE:
Asynchronous, which keeps everything in memory, but eventually flushes in-memory changes into persistent storage (i.e. IndexedDB). This is necessary, since IndexedDB itself asynchronous and if we want to keep good performance by preventing turning Java methods into state machine, we can use this implementation. This implementation would also require that main method starts asynchronously to make sure that all data read from IndexedDB into memory.
Synchronous, which never keeps data in memory, and all reads/writes all data 'synchronously', from Java's standpoint.
The text was updated successfully, but these errors were encountered:
Current implementation of FS in JS keeps everything in memory. In real world cases users may want to keep their files in persistent storage. Filesystem support in TeaVM already relies on interface, which has implementations (in-memory and WASI), so it's only a matter of providing extra implementations as well as a way to pass compiler the name of desired implementation (TeaVM properties can be used for example).
It's reasonable to have two additional implementations for JS BE:
main
method starts asynchronously to make sure that all data read from IndexedDB into memory.The text was updated successfully, but these errors were encountered: