-
Notifications
You must be signed in to change notification settings - Fork 418
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add custom I/O executor support to I/O objects.
All I/O objects now have an additional Executor template parameter. This template parameter defaults to the asio::executor type (the polymorphic executor wrapper) but can be used to specify a user-defined executor type. I/O objects' constructors and functions that previously took an asio::io_context& now accept either an Executor or a reference to a concrete ExecutionContext (such as asio::io_context or asio::thread_pool). One potential point of breakage in existing user code is when reusing an I/O object's io_context for constructing another I/O object, as in: asio::steady_timer my_timer(my_socket.get_executor().context()); To fix this, either construct the second I/O object using the first I/O object's executor: asio::steady_timer my_timer(my_socket.get_executor()); or otherwise explicitly pass the io_context: asio::steady_timer my_timer(my_io_context);
- Loading branch information
1 parent
a72fbb0
commit 59066d8
Showing
163 changed files
with
8,245 additions
and
5,159 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
59066d8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A number of consumers no longer build. Can you help analyzing? It looks like the issue is within Boost.
59066d8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
io_object.get_executor()
no longer returnsio_context::executor_type
, the default executor is nowasio::executor
(a polymorphic executor). In order to get old behavior you need to use different type, e.g. for sockets you needasio::basic_stream_socket<asio::ip::tcp, asio::io_context::executor_type>
. Alternatively just don't useget_executor().context()
and just passget_executor()
to the constructors.59066d8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Several of these errors are due to this line:
https://github.com/zaphoyd/websocketpp/blob/master/websocketpp/transport/asio/security/none.hpp#L172
where it is passing a constructor argument through
make_shared
in areference_wrapper
. This shouldn't be required asmake_shared
will perfectly forward its arguments.EDIT: I've noted this on an existing websocket issue for this problem: zaphoyd/websocketpp#794 (comment)
59066d8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That won't work with
boost::make_shared
and pre-C++11 compilers. On those compilersmake_shared
forwards parameters by const reference:Is there a known workaround for the old compilers?
59066d8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you only need to support the forthcoming boost release, then:
If you want to support both old and new boost versions then obviously you could just use
new
directly and construct ashared_ptr
from that, but to continue usingmake_shared
you could try something like:59066d8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chriskohlhoff is the workaround suggested in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236601 namely something along the lines of
an acceptable workaround for old and new boost versions?
59066d8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(boost::asio::io_context&)(s).get_executor().context()
this cast is unsafe, do you actually need theio_context&
? 1.70 added constructors to sockets and other I/O objects that allow constructing directly from an executor. So if this macro is to be used to construct a socket, it should be:59066d8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@djarek Thanks for the quick reply. Could you help me develop a simple, short fix for something like nghttp2/nghttp2#1320 that is dispatched on
BOOST_VERSION
? We're getting a lot ofio_context
related failures with boost 1.70, and I'm looking for a simple canonical fix.59066d8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SoapGentoo that macro should work just fine, you can wrap it into a function if you don't like spilling macros everywhere.
59066d8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The line that caused us (Wesnoth) problems was
We resolved the issue by removing the use of
std::ref
(it's redundant anyway).