-
Notifications
You must be signed in to change notification settings - Fork 4
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
Remove Boost Coroutine as a hard dependancy #5
Comments
Once the generilsation of the API is done as described in #5 then this should compile and the test pass.
I share your concerns about this making the code a lot more complex. I'm
curious how much different it's going to be.
…-- Ben
On Sat, Jun 3, 2017 at 2:01 PM, Kirit Sælensminde ***@***.***> wrote:
There is a standard API for allowing a wider range of async mechanisms,
including the upcoming built-in coroutine support and call backs -- for
those mad enough to want them :)
@vinniefalco <https://github.com/vinniefalco> has offered to help advise
on this, so I"m obviously going to take him up on his kind offer. I've
already got a branch where I've started to put together some tests, so I
think converting the call stack that handshake uses is probably a good
place to start, as per his suggestion
<https://www.reddit.com/r/cpp/comments/6ezlg4/interoperability_between_the_networking_and/dieaqz2/>
.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#5>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA1n_xqLU4q1vEU8c_AzSCoehwzUUNb0ks5sAQTFgaJpZM4NvARt>
.
|
It all depends on how hard you're willing to work to make the library the absolute best it can be. |
The way that I"m looking at this is that in the short term there are more features the library needs to be useful at least for us, so I think that the 1.0 roadmap of only supporting Boost coroutine seems reasonable to me. In the future I think it depends on what way the rest of the community also jumps. Having written a load of callback based ASIO code in the past I know just how hard it is to get right. The code is typically at least three times as long, and if I'm writing it, likely to contain ten times the bugs. And all because we have to do manually a program transformation that the compiler can do automatically, and this to support a couple of additional ways of the library: callbacks and future/then. I think this is fairly well borne out given Vinnie's tutorial on "composed operations" (or "universal async" as I've been thinking about it). All of that code, as far as I can tell, is approximately this with coroutines:
My hope is that once coroutines are in compilers they'll get adopted so quickly our heads will spin and the use of callbacks just won't be anything anybody wants to deal with. Gor Nishanov (who wrote Microsoft's coroutine implementation and has just done clang's) has an interesting piece showing the shims needed to interface coroutines with futures. This appears to already be available for The time period the "not now" covers is really only until issue #6 is done, which really oughtn't be much longer than a couple of weeks from now. In the meantime the branch for this is feature/universal and the very first thing I'd have to do is to work out how to implement the |
I agree with almost everything except for this one statement:
The problem is that each running coroutine requires its own stack. This consumes a ton of resources for a server that needs to handle tens of thousands of connections. The stack must be maintained even if the connection is not currently being serviced. Now compare that with callbacks and composed operations, the amount of memory is equal only to |
There is a standard API for allowing a wider range of async mechanisms, including the upcoming built-in coroutine support and call backs -- for those mad enough to want them :)
@vinniefalco has offered to help advise on this, so I"m obviously going to take him up on his kind offer. I've already got a branch where I've started to put together some tests, so I think converting the call stack that
handshake
uses is probably a good place to start, as per his suggestion.The text was updated successfully, but these errors were encountered: