Implement fibers #913
Implement fibers #913
Conversation
Instead of making `Promise` friend everything that needs to construct a `Promise<T>` from an `Own<PromiseNode>` or vice versa, let's just friend `PromiseNode` itself -- which is already a "private" class by virtue of being in the `_` namespace -- and let it provide some static methods to do the conversions.
|
Fascinating! I was worried when I saw the title of this pull request, as it calls to mind Meteor fibers, which allow any function to yield control back to the event loop. That makes it difficult to implement critical sections; you need to know that all functions you call are not secretly async. The |
Fibers allow code to be written in a synchronous / blocking style while running inside the KJ event loop, by executing the code on an alternate call stack and switching back to the main stack whenever it waits. We introduce a new function, `kj::startFiber(stackSize, func)`. `func` is executed on the fiber stack. It is passed as its parameter a `WaitScope&`, which can then be passed into the `.wait()` method of any promise in order to wait on the promise in a blocking style. `startFiber()` returns a promise for the eventual value returned by `func()` (much as `evalLater()` and friends do). This commit implements fibers on Unix via ucontext_t. Windows will come next (and will probably be easier...).
It was so easy that it compiled on the first try and almost totally worked... only thing I missed was calling switchToMain() explicitly at the end of the fiber main func.
While swapcontext() exists on Cygwin, it seems that throwing an exception in a stack other than the main stack leads to a hang. But the Win32 fiber API seems to work fine.
|
OK, this now passes all CI, yay! |
|
|
||
| KJ_EXPECT(exited); | ||
| } | ||
|
|
There was a problem hiding this comment.
What would this do?
kj::Promise<void> fiber;
fiber = startFiber(65536, [&](WaitScope& fiberScope) {
fiber.wait(fiberScope);
});or also
kj::Promise<void> fiber;
fiber = startFiber(65536, [&](WaitScope& fiberScope) {
fiber = nullptr;
});If they crash, that's great. If they throw an exception, then they might be worth a test. Hopefully there's no third option. :)
There was a problem hiding this comment.
The first one will deadlock. Arguably this is the correct behavior: The fiber is waiting for itself to be done. But it won't be done until it finishes waiting. So it's never done. This sort of thing isn't unique to fibers; you can create promise loops with regular promises too. It's probably impractical to try to detect, especially when you have a complex chain of promises with forks and joins and such.
The second one will call ::abort() on line 866 of async.c++.
|
Why fibers instead of UMS threads? Fibers are pretty limited when comparing the two. But then again, maybe the c++20 co_await is where everything should be headed? Has anyone used capnp w/ emscripten? Leveraging asio might be a more generic way to achieve the end goal of an extensive CSP (communicating sequential processes) framework on every platform, and across any communication medium. At a minimum, the promise implementation and executor look highly useful. |
|
@unicomp21 Thanks for your comment, but I think you've misunderstood what's happening here. KJ (the C++ toolkit library under Cap'n Proto) has featured an async I/O framework based on Promises for seven years now. It is better than asio. We introduced fibers as a compatibility hack. Fibers allow us to call into libraries that are designed to operate in a synchronous way -- with synchronous callbacks -- within an async event loop. We explicitly do not want fibers to behave like threads. We also plan to support async/await with KJ Promises soon (they are a perfect fit). But, while async/await is absolutely beautiful in new code, it wouldn't allow us to call into existing synchronous code the way fibers do. |
|
Aaah, got it, thanks @kentonv ! |
Fibers allow code to be written in a synchronous / blocking style while running inside the KJ event loop, by executing the code on an alternate call stack and switching back to the main stack whenever it waits.
We introduce a new function,
kj::startFiber(stackSize, func).funcis executed on the fiber stack. It is passed as its parameter aWaitScope&, which can then be passed into the.wait()method of any promise in order to wait on the promise in a blocking style.startFiber()returns a promise for the eventual value returned byfunc()(much asevalLater()and friends do).WIP DO NOT MERGE: I haven't done Windows yet. But it should be easy since Windows' fibers API is actually really good. Putting up this PR now to get ahead of MacOS failures.