Remove Boost Coroutine as a hard dependancy

[KayEss]

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.

[scherrey]

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

[vinniefalco]

It all depends on how hard you're willing to work to make the library the absolute best it can be.

[KayEss]

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:

  char data[max_length];
  size_t length = sock->read_some(boost::asio::buffer(data), yield);
  boost::asio::async_write(*sock, boost::asio::buffer(data, length), yield);

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 std::futures though, and the code looks like something we can work with quite easily.

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 unix_domain_socket helper function.

[vinniefalco]

I agree with almost everything except for this one statement:

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.

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 sizeof(composed_operation_state) when the callback is not invoked.