Apparently WASI start and WebAssembly start are two seperate functions

[jtenner]

I just want to open a discussion to get everything all squared away, and come to a consensus to aid in my development of the lunatic lib. I have found myself confused and misunderstood, mostly because I always seem to know enough to get myself into trouble 😂.

I know that each module, when instantiated, must initialize it's memory properly. This means calling what I will refer to here as the WebAssembly.Start method, which conflates with the apparently different WASI._start() function.

Of course, I'm going to advocate for lunatic here, and I can hopefully describe how lunatic works. When lunatic spawns a thread, it calls the WebAssembly.Start method. If ASC_WASI is defined, it leaves memory uninitialzed, and plenty of undefined behavior starts to occur. So I've have to make some changes to make my tests pass as a result, and they feel wrong. Take the following asconfig as an example:

// asconfig.json
{
  "targets": {
    "debug": {
      "debug": true
    }
  },
  "options": {
     // We need to redefine these, even though I would like to use the ones provided by the std lib
    "use": ["abort=abort","trace=trace","seed=seed"],
    "lib": ["assembly/"],
    "exportTable": true
  }
}

Aside from redefining a custom abort, trace and seed method, I also have to export a _start() function manually from the module entry point. This breaks my expectations, because when I want to use "wasi", the documentation suggests to import "wasi".

If I might suggest a more elegant solution to this issue, we could try the following:

1. Memory and setup stuff should end up in WebAssembly.Start function. We can tell it's memory and setup function because they exist in lib entry points. EG, everything in rt/* and also everything provided as a lib entry point by design.
2. If ASC_WASI is defined, any top level statements in module entry points could end up in the WASI._start() function instead. This will enable developers to ensure that WASI calls their start methods once, at least in spirit.

As far as I can tell, this might actually be intuitive and expected behavior. Personally, I am mostly unsure how other CLI tools handle the different methods, so maybe I'm wrong. I'm open to discussion.

In short, I would love to return to this:

import "wasi";

Instead of this:

export function _start(): void {}

Given my current available workaround, I'm okay if this seems like an unreasonable request. These issues can be documented on the as-lunatic package, and I can move on with my life. I'm just curious if my idea makes sense?

Thanks for everyone's help with today's discussion, and I'm happy to report all my tests pass because of this effort. I'm glad to avoid undefined behavior. 👍

[dcodeIO]

I agree that we need a better story there, the current behavior doesn't seem right. Would suggest to remove the special import "wasi"; behavior, so one can control generation of _start by either providing --explicitStart to achieve the same as the compiler currently does, or not use --explicitStart to have the option to emit both an implicit and a manual explicit start akin to a C main function defined in the entry file.

[jtenner]

Ideas I have.

asc entry.ts --wasiStart=symbol
asc entry.ts --use ASC_WASI_ENTRY=symbol

export function _start(): void {}

// potential decorator?
@wasiStart export function main(): void {}

Again, per my suggestion, any user entry files could be attached to the _start() method, and lib entry statements could be attached to the WebAssembly.Start method.

I definitely want this:

import "wasi";

[dcodeIO]

I am not suggesting to remove import "wasi";, just that it doesn't imply --explicitStart anymore.

[jtenner]

Ah. I misunderstood. This is just fine. It's the smallest change and produces the largest results.