ozo
ozo copied to clipboard
yandex
Build fails with Boost.ASIO 1.74
There is some issue with executors in latest Boost.Asio version. Looks like the problem is that the default executor now is a specialization of boost::asio::any_executor template which is incompatible with boost::asio::executor as they model the different Executor concepts. Looks like the problem is in resource_pool library - https://github.com/elsid/resource_pool/blob/6a4074465cc672fc1999035ef3e851d7c250134c/include/yamail/resource_pool/async/detail/pool_impl.hpp#L105
Just FYI: The title is a little misleading, as this happens with Boost.ASIO 1.74, regardless of the platform.
I've already tried to fix this, but in the end I failed to get the unit tests running, as the executor interface was completely changed. Maybe it still helps as a starting point.
Thanks, Jonas!
Looks like I'm a little bit out of sync with Boost.Asio changes. It looks like there are two Executor concepts - Networking TS Executor and Executors TS Executor. And they are not compatible with each other. I think I should learn more about this situation.
Anyway, thanks for your try. I think this is a good point to start with.
Looks like I'm a little bit out of sync with Boost.Asio changes. It looks like there are two Executor concepts - Networking TS Executor and Executors TS Executor. And they are not compatible with each other. I think I should learn more about this situation.
You're right. The changelog even mentions a solution regarding the polymorphic executor, but I don't think requiring the user to define BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT in order to use resource_pool/ozo is a solution for the long run. Also, some other things were not compatible with the new executor model, for example io_context::strand. Vinnie Falco suggested just using strand instead on the cpplang slack, which does work -- but that thing is cumbersome to construct without make_strand, the latter being available only from Boost 1.70ish and up.
Anyway, thanks for your try. I think this is a good point to start with.
Sorry for being of so little help, I just hoped it would be a quick fix, but turns out it wasn't -- and with 1.73 being ok for my purpose, I didn't really want to spend the time to deep-dive into a completely new execution model.
Well, looks like we need to define BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT for the time #272 since all the tests that use Executor models need to be rewritten - a lot of work, unfortunately. But we need to build on the Mac OS at the moment.