Add emscripten fiber.h api

[unicomp21]

This might also be needed by:
#376

But, I'm thinking having fiber.h will be enough to get started creating an AssemblyScript CSP framework (communicating sequential processes) similar to golang goroutines and channels.

[dcodeIO]

I don't see fibers to become relevant any time soon in AS, since JS, and in turn TS, and in turn AS are not designed for in-process threading. The closest thing there is are WebWorkers, i.e. cooperative processes with copying in between. If you have something in particular in mind in that regard, please elaborate, but note that fibers are very likely not applicable.

[MaxGraey]

I don't think fibers is good approach for our design. Fibers based on stackful coroutines / green threads and required direct access to shadow stack for saving / restoring context "resume" / "suspend" (wasm hasn't shadow stack and simulation this only for fibers quite unnecessary). Also fibers required event loop (scheduler), threads, atomics, mutex. Which also not always possible due to Wasm MVP hasn't threads and some engines like wasmtime / lucet / wasmer didn't implement this proposal yet.

Much better approach is building async / await over generators which based on "asymmetric stackless coroutines". It pretty similar how works async / await in javascript and C#. This could implement similar to regenerator without any requirements for host env and extra proposals.

https://www.youtube.com/watch?v=KUhSjfSbINE

[MaxGraey]

Regarding emscripten's fiber. It's not "real fibers", just some form of single threaded simulation with stack and threads emulation which required a lot of javascript glue code

[unicomp21]

Agree, true async/await would be really nice to have. But, emscripten fibers are available and ready to use "now". Why not have both?

[unicomp21]

@dcodeIO @MaxGraey think I may have created some confusion. Fibers are a single-threaded concept. Multiple fibers run on the same cpu thread. ie multiple fibers can run on the main browser thread. With a scheduler they can swap in/out on the main thread cooperatively. Think of them as virtual threads which can run on the main browser thread. Because they swap in/out cooperatively the performance can be better than real threads, which flush the cpu pipeline when they hit a lock. Granted, for large vector array computations (SIMD) there is no substitute for multiple CPU threads. But, if all we're doing is multiplexing i/o, and manipulating non-vector array data, fibers can perform quite well, and eliminate the problem of "callback hell", much like javascript promises.

[MaxGraey]

Again, fibers have several problems:

• required scheduler (even loop) on host
• required emulation of shadow stack
• required a lot of glue code

Asymmetric stackless coroutines which actually just codegeneraated state machine and don't required .glue code, scheduler and stack. The main drawback of stackless approach it will be slightly more complicated in implementation

[unicomp21]

required a lot of glue code

I'm confused, how does fiber.h mandate a bunch of glue code? From what I can tell, they've already done the hard part. We just need to add it.

@MaxGraey

[MaxGraey]

I'm confused, how does fiber.h mandate a bunch of glue code?

Full implementation of fiber concept on wasm require it. To be more precise, saving and restoring the context of the emulated stack and handling scheduler. fiber.h is just api declaration. It doesn't do anything

[unicomp21]

Right, we have a really nice "working" implementation, why not use it?

[MaxGraey]

Right, we have a really nice "working" implementation

Where?) All we have is emscripten specific implementation which really depend on browser

[unicomp21]

In emscripten, which is used to build Assemblyscript, right?

[MaxGraey]

We don't use emscripten) Only binaryen

[unicomp21]

That's great because binaryen is what handles the fibers.

https://emscripten.org/docs/api_reference/fiber.h.html?highlight=emscripten_fiber_swap

[MaxGraey]

binaryen only expose low level mechanism called Asyncify.

[unicomp21]

emscripten = clang + binaryen + emsdk

binaryen only expose low level mechanism called Asyncify.

fiber.h sits on top of that layer, right?

[MaxGraey]

emscripten = clang + binaryen + emsdk

Right. Also js specific glue code which emulate many things like threads, handling fiber's contexts, shadow stack, bind web api, dynamic function casts and etc. AssemblyScript has quite different and own technology stack which use only binaryen from that set.

[unicomp21]

quite different

what's so different?

[dcodeIO]

Fibers are a concept used by certain programming languages to implement certain language features. AssemblyScript, however, is based on JavaScript, with its concepts of async and await and WebWorker, none of which require an intermediate concept of fibers. It is right that these can be implemented on top of Binaryen's asyncify. but arguing for some random fibers header from the internet specifically doesn't make any sense.

[MaxGraey]

what's so different?

First of all own compiler's frontend and backend. Own standard library. Everything different. AS and emscripten share only Binaryen, but even this library used slightly differently. AS uses own binaryen's pass pipeline and don't apply many specific only for emscripten passes.

[jtenner]

Sounds like someone could make a library called fiber-as. Or maybe fibas. Scheduling tasks like that would be very useful. Probably not meant for the assemblyscript std lib.

[unicomp21]

what's better, a "channel" (ie like golang) or a "promise" like javascript. one could argue a channel is simply a promise which has "evolved". A channel can be used in place of a promise.

I'm clearly advocating something like goroutines and channels, implemented w/ fiber.h

[unicomp21]

so I guess what I'm hearing is we already have low level asyncify hooks as seen here

#1436

but bringing the abstraction up a little higher is out of the question?

https://github.com/AssemblyScript/assemblyscript/blob/8a55531dfd8527cf96d8557fdc25c3603fa49ae9/std/assembly/bindings/asyncify.ts

[MaxGraey]

C++20 coroutines, Rust's coroutines, C# coroutines and at last JavaScript generators and async/await. All that languages have stackless coroutines because it has a lot of advantages.

[MaxGraey]

Also you could be interesting in comparison results of tokio (stackless coroutines) vs "may" (stackful coroutines) and interesting comment from author

[unicomp21]

Would love to have this in the browser ...

https://github.com/chriskohlhoff/asio/search?q=co_await&unscoped_q=co_await