[5.0] PH: Post on resolver strand to ensure execution on strand #1863
Conversation
|
I don't see the benefit of using a different strand for |
No benefit I see either. I'll fix it. |
| boost::asio::post( resolver_.get_executor(), [host, port, self=this->shared_from_this()] { | ||
| self->resolver_.async_resolve( | ||
| host, std::to_string(port), [self](beast::error_code ec, auto res) { self->on_resolve(ec, res); }); | ||
| }); |
There was a problem hiding this comment.
Does this change make a difference? I would have thought that, since we provide an executor when building the resolver, the async functions would already be posted on this executor?
There was a problem hiding this comment.
This code follows the example of libs/beast/example/http/client/async/http_client_async.cpp however I think it would be better to follow https://www.boost.org/doc/libs/1_83_0/libs/beast/example/http/client/crawl/http_crawl.cpp as that is a multi-threaded example. I'll close this PR and create a new one with those changes.
Unable to get anything meaningful from the core dumps of the failed test of #1858. Before this change the
async_resolvewould run on the main thread even though the resolver was given a different thread to execute on. This change makes sure the resolver is only touched by the resolver thread.Resolves #1858