feat: WASI support for browser runtime #196
Conversation
|
Oh, these also may need to be executed if they exist: Line 344 in e3a427b |
Any program meant to be run in a WASI environment shouldn't be expecting additional initialization calls beyond _start. |
Those calls are being done instead of |
browser/src/plugin.ts
Outdated
| @@ -82,6 +82,9 @@ export default class ExtismPlugin { | |||
| env: environment | |||
| }; | |||
| this.module = await WebAssembly.instantiate(this.moduleData, env); | |||
| if (this.module.instance.exports._start) { | |||
| wasi.start(this.module.instance); | |||
There was a problem hiding this comment.
I don't think we want to call _start here, since that will actually run the plugin, it should be called in Plugin.call instead
There was a problem hiding this comment.
@zshipko so, you mean it should adopt the same methodology we use in the Rust runtime?
There was a problem hiding this comment.
yeah i don't think it should ever automatically be called, the user should call it themselves (that's how it's handled in the Rust runtime)
also, after _start is called the module should be reinstantiated before any function can be called again.
closes #160
Goal is not to expose all the WASI functionality, but to just write minimum code to allow PDK targets that require WASI (e.g. tinygo compiled plugins) to work in the browser. We can follow up with allowing the user more control over the WASI environment.