Jacob Lifshay

i think you can probably end up with a pretty efficient JS implementation using wasm GC by using the hidden classes and inline caching technique that V8 uses -- that...

seems to me that you're basically just missing the equivalent of [`tokio::task::spawn`](https://docs.rs/tokio/latest/tokio/task/fn.spawn.html). I think this could be implemented in the component model by components having a new quiesce entry point,...

something kinda like this pseudocode: ``` component a: def quiesce() -> future: ... def foo() -> future: ... component b: local needs_quiesce = false local spawned_tasks = [] def quiesce()...

One potential misunderstanding I spotted: I expect to be able to call another entry point in a component while a future returned by a previous call hasn't completed yet, this...

> At first I thought this might only be the way StarlingMonkey is currently implemented, but I now think the problem is more fundamental than this, and you can see...

to be clear, the kind of polling I am thinking of is like in Rust async/await, where every poll invocation has a waker that it can register to be called...

Looks good to me! Should we also address potential races with other processes and/or threads or just leave that unaddressed as out-of-scope-for-now?

> You're proposing removing `proc_exit`? I get that the "proc" prefix is problematic, but there should be some way of exiting early from a wasi instance in my opinion. Perhaps...

For SIGINT (and other signals that you want to handle even if the rest of your code is in the middle of something), spawning a new thread to run the...

there are some license files: https://github.com/WebAssembly/WASI/blob/master/tools/witx/LICENSE there may be more that I missed.