Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement fibers #913

Merged
merged 4 commits into from Dec 6, 2019
Merged

Implement fibers #913

merged 4 commits into from Dec 6, 2019

Conversation

kentonv
Copy link
Member

@kentonv kentonv commented Dec 4, 2019

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).

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.

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.
@dwrensha
Copy link
Member

dwrensha commented Dec 4, 2019

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 WaitScope& parameter neatly solves this problem. Functions that can yield should have such a parameter, thus statically declaring that they are async.

@kentonv
Copy link
Member Author

kentonv commented Dec 4, 2019

@dwrensha Indeed. Note this design was introduced six years ago (exactly, as of today), before I'd worked much with Meteor fibers: fecb608 😏

kentonv added 3 commits Dec 5, 2019
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.
@kentonv
Copy link
Member Author

kentonv commented Dec 5, 2019

OK, this now passes all CI, yay!

Copy link
Member

@harrishancock harrishancock left a comment

I can't wait to use this. :)

I had a couple test ideas, but go ahead and merge whenever.


KJ_EXPECT(exited);
}

Copy link
Member

@harrishancock harrishancock Dec 6, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. :)

Copy link
Member Author

@kentonv kentonv Dec 6, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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++.

@kentonv kentonv merged commit 000e2a9 into master Dec 6, 2019
@kentonv kentonv deleted the fibers branch Dec 6, 2019
@unicomp21
Copy link

unicomp21 commented Aug 19, 2020

@kentonv

Why fibers instead of UMS threads? Fibers are pretty limited when comparing the two.
https://docs.microsoft.com/en-us/windows/win32/procthread/user-mode-scheduling

But then again, maybe the c++20 co_await is where everything should be headed?

Has anyone used capnp w/ emscripten?
https://emscripten.org/docs/api_reference/fiber.h.html

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.
https://github.com/chriskohlhoff/asio/search?q=co_await&unscoped_q=co_await
(unfortunately, we don't yet have something similar in emscripten)

@kentonv
Copy link
Member Author

kentonv commented Aug 20, 2020

@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.

@unicomp21
Copy link

unicomp21 commented Aug 20, 2020

Aaah, got it, thanks @kentonv !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants