WebAssembly fibers

[Mark Sibly]

Hi,

Is there any support planned for something like 'fibers' in WebAssembly?

Basically, this is just super simple cooperative threading that allows you to do (a form of) async programming. The Windows API supports fibers via CreateFiber and SwitchToFiber (and that's about the whole API)  No other OS's do I think (although they apparently used to via 'contexts').

The language I am writing that transpiles to c++ supports fibers thanks to the boost.coroutine package. This contains equivalent versions of CreateFiber and SwitchToFiber for a ton of OS's (written in ASM of course), including windows, linux, macos, android, ios. It works great and I don't actually even use the coroutine stuff.

You can do some cool stuff on top of fibers - boost.coroutine does coroutines (generators?) in pure c++ on top of them, and there is even a proposal around for c# style async/await etc in c++ using fibers.

I haven't had a whole lot of experience with this stuff, but I find fibers incredibly useful, super simple and think they would be a very cool addition to WASM. Especially, of course, for my needs so yes, there's a bit of self interest here...

Dunno, this is probably not the right place to be mentioning it, but I just wondered if anyone knew whether something like this is happening?

And if not here, where should I be asking questions like this?

Bye!

Mark

[Jukka Jylänki]

This is definitely the right forum for these types of questions.

Reading MSDN docs on Fibers, it seems that SwitchToFiber()ing will freeze the currently executing fiber on the current thread, and jump the thread over to the call stack of the another fiber and resume its execution, and later SwitchToFiber()ing back will freeze the other thread's callstack where it was going, and resume from the callstack of the first thread.

This kind of feature requires that one is able to capture function callstacks and resume from them. Unfortunately it is not possible to manipulate the callstack of a thread, even with upcoming pthreads, so this is not natively possible, except by allocating a native pthread for each fiber.

Emscripten does however have the Emterpreter feature, where Emscripten includes a bytecode interpreter to the compiled output, which executes the code. That would be able to implement fibers support. I'm not sure if that would be of interest here though?

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Sibly]

Emterpreter would be an option I guess (I haven't actually used it) but it sounds like it'd be slowish and could only be used in particular situtations. It'd also likely be hard to use in a 3rd party language that transpiles to c++ (unless you just interpreted the whole thing I guess, probably not a good idea?). I'm after a much more general purpose feature that could be used anywhere/everywhere. I think there's a good chance wasm will end up as a target for many transpilers, where 'emscripten specific' stuff like emterpreter and the currently limited thread system are less useful.

Fibers can be done on top of threads with semaphores, but at a pretty big cost (ie: the thread switch). Fiber switching has little more overhead than a function call, as all they really do is push/pop callee save registers and the PC. The ASM code in boost.coroutine is very minimal, just a few pages long.

I've done a few write ups on my experiences with fibers here:

http://monkey2.monkey-x.com/2016/07/16/latest-developments/

http://monkey2.monkey-x.com/2016/02/01/func-with-fibers/

Not sure how exactly fibers could be done in wasm (don't know enough about it), but a starting point would be to use the internal boost.coroutine make_context and jump_context ASM code. This is already provided for a lot of targets, but you'd have to write new versions for any unsupported targets.These would have to execute natively in the browser of course - but one kind of nice thing about fibers is they don't go off 'behind your back' so this should be OK? Pre-post jump_context code can also easily be added if necessary when code is JIT 'compiled' in the browser. ALL in all, I don't think it'd be huge deal (famous last words...) but it's something I think would have to be done at the 'browser level' as it'll interact with stacks etc.

ps: It looks like the bit of boost.coroutine I'm talking about is now called boost.context.

pps: It looks like this stuff also used to be in the clib via <ucontext.h> but is now obsolete.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/oPcwUGPZFJo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Floh]

The interesting part of boost.context is here: 

https://github.com/boostorg/context/tree/develop/src/asm

If I read this right it basically saves the entire CPU state (including the stack ptr) to one 'context', switches to another 'context', loads this new context's CPU state (including new stack ptr) and jumps to the context's resume address, basically like cooperative multitasking back in Windows 3.1 :)

As far as I can see there's not much info about this in the WebAssembly design documents, only a short mention here: https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#coroutines, I don't think it can currently be implemented, without explicit low-level support in wasm.

I agree that it would be nice to have, but I'm not holding my breath ;)

-Floh.

[Alecazam]

Fibers seem great until you have to step through and debug them. They need special debugger support, which wasn't there in VS for a while. I'll just be happy for wasm threads.