replace boost.coroutine by boost.context in spawn() #55
Conversation
olk
commented
Sep 30, 2017
olk
commented
- boost.context is deprecated (preprocessor warnings)
- use boost.context instead (call/cc) instead
- C++11: use callcc()/continuation from boost.context
- pre-C++11: use private fcontext-API from boost.context
- boost.context is deprecated (preprocessor warnings) - C++11: use callcc()/continuation from boost.context - pre-C++11: use private fcontext-API from boost.context
| @@ -41,25 +42,25 @@ The first argument to `spawn()` may be a | |||
| [link boost_asio.reference.io_service__strand `strand`], | |||
| [link boost_asio.reference.io_service `io_service`], or | |||
| [link boost_asio.reference.CompletionHandler completion handler]. | |||
| This argument determines the context in which the coroutine is permitted to | |||
| This argument determines the context in which the contnuation is permitted to | |||
|
Any update on this feature? |
|
@jaycelq, you could use an alternative completion token that implement the same functionality if you're in a hurry: https://github.com/blinktrade/iofiber (documentation). |
|
Any update on this feature? |
| *ec_ = boost::system::error_code(); | ||
| if (--*ready_ == 0) | ||
| (*coro_)(); | ||
| *ec_ = boost::system::error_code(); |
|
hi @olk, i worked through the merge conflicts and pushed the result to https://github.com/cbodley/asio/commits/wip-spawn-context. there are a number of new spawn() overloads from the networking ts changes, and the new StackAllocator templates caused some ambiguities that motivated an |
|
given that this spawn() interface a) isn't part of the C++ Networking TS and b) has since been superceded in asio by co_spawn(), it seems that there isn't much interest in maintaining or extending it in asio i ended up forking this spawn() implementation in https://github.com/cbodley/spawn, sans c++98 compatibility, so that it can be used on top of an umodified version of boost::asio (and eventually std::net). many thanks to @olk for this contribution |
|
spawn() and co_spawn() use two different kinds of coroutines: stackful vs stackless. Porting between those two is not trivial. If no work is done to upgrade spawn() to new version of coroutine2 then the only option is to deprecate it along with coroutine1 forcing any people who want stackful coroutines to either implement own completion tokens/spawners or use third party ones. |
From experience, I can tell that a serious stackful coroutine token implementation will in no time evolve into a fiber token. I no longer see a point in adding just a stackful coroutine token. OTOH, if you're using fibers, maybe you should go to something other than Boost.Asio entirely. As Oliver Kowalke explained in https://wg21.link/p0099, you can use symmetric coroutines to cut the number of context switches in half, but Boost.Asio execution engine doesn't actually allow you to explore this property (so in the end it only performs as good as asymmetric coroutines). Unfortunately, Boost.Fiber doesn't play very well with IO (the lack of a cancellation API being the major problem). My current view is that a new IO fiber library should be developed evolving from Boost.Fiber API and adding cancellation (the cancellation API is enough to change semantics and break behaviour, so enough of a motivator to not change current Boost.Fiber) + strands. But then again, that's a lot of work. I'm personally fine using Boost.Asio with a hand-rolled fiber token. That's way less work and it'll give me integration with the few Boost.Asio libraries that go to great lengths to implement the whole completion token and executors protocols (not many) and even greater lengths to adapt to the API breakage that happens at every release since the networking TS folks got their claws deep into Boost.Asio. One of the major selling points in Boost.Asio that can't be easily replicated in new projects is the maturity it got over the years by working around the many quirks that OS-specific APIs have. That's a lot of value already, aye. |
cbodley has implemented a completion token based on boost.context - I don't know why it hasn't been merged (pull request was provided?. |
You're most likely suffering from complexity addiction. I merely want to simplify a mess of handlers in a server using coroutines that spell out what is going on there more clearly. Asymmetric stackful coroutines are just fine for this. |
Not really. There is very little difference between stackful coroutines and fibers. You just lack this understanding. And Boost.Asio execution engine already covers the role of the extra mile that fiber adds: concurrency orchestration. Once you're there, you're just properly exposing Boost.Asio features to the “coroutine” token (and then you have no differences between a fiber token and a coroutine token). Other than that, you'll only miss a fiber token when you need to tame the concurrency and that only happens on complex projects (the last project I worked with had very peculiar routing requirements, so that's my background here).
Here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf |
|
Only thing that matters to me is ability to suspend while saving context. And do so without using any C++ features not present in C++14. And not have to maintain own token when one is available in asio. I suppose implementing asio::spawn() and asio::yield() directly in terms of boost.context would also achieve this without depending on deprecated coroutine1. |
Been there. Done that. A fiber token will not complicate your use case. It's Anyway, my initial comment was targeting people putting the implementor hat. It's not surprising that you (the one who only wears the user hat) didn't find it useful. Enough of this thread. Have a good day. |
|
Please consider boost.spawn |
