Hi Sorin, This is a known issue in ASIO - `asio::use_future` has an associated executor (which is used to redirect exceptions), but the problem is that the implementation doesn't use the `associated_executor` type trait to wrap an executor associated with the I/O object that is used. Instead, it uses the intrusive executor hook, which "overrides" the executor associated with the I/O object. Note that if `bind_executor` were to work with it, it would cause the exception redirection to break. As a sidenote: asio::io_context::strand is deprecated and should not be used in projects that use ASIO 1.66+. You should use `asio::strand` instead. On Mon, Dec 17, 2018 at 6:23 PM Sorin Fetche via Boost-users < boost-users@lists.boost.org> wrote:

On Sun, Dec 16, 2018, 11:52 PM Richard Hodges wrote:

...

I've been discussing a very similar thing with Vinnie Falco, here: https://github.com/boostorg/beast/issues/1366

On Mon, 17 Dec 2018 at 13:39, Sorin Fetche via Boost-users < boost-users@lists.boost.org> wrote:

...

Is there a way to combine the special use_future completion token with a strand?

...

If this is not currently possible, shouldn't it be an issue (bug/missing feature) of Asio?

Initially, when writing the code, I was kind of expecting that asio::bind_executor works with asio::use_future, but the compiler disagreed with me. So, I think I'll raise an issue on this against the Boost.Asio library.

Best regards, Sorin

...

_______________________________________________

Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

On 18/12/2018 07:26, Damian Jarek wrote:

As a sidenote: asio::io_context::strand is deprecated and should not be used in projects that use ASIO 1.66+. You should use `asio::strand` instead.

That seems like a poor tradeoff of names. I hope the former will never be removed and will just typedef to the latter.

On 19/12/2018 12:37, Vinnie Falco wrote:

On Tue, Dec 18, 2018 at 2:46 PM Gavin Lambert wrote:

...

That seems like a poor tradeoff of names. I hope the former will never be removed and will just typedef to the latter.

Do you think that when Networking TS is merged to the standard in 2026, that it should also have both `std::net::strand` and `std::net::io_context::strand`?

That's a false equivalence. If the question is whether these should both exist: std::net::strand<Executor> std::net::io_context::strand Where the latter is a typedef/using to std::net::strandstd::net::io_context::executor_type ... Then absolutely, yes, both of these should exist. Convenience typedefs are not redundant, especially where they both save typing and are logically easy to find. Now, if std::net::strand wasn't templated on the executor type, then that might change the answer.