Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

io_context replace io_service #110

Closed
snahmad opened this issue May 10, 2018 · 9 comments
Closed

io_context replace io_service #110

snahmad opened this issue May 10, 2018 · 9 comments

Comments

@snahmad
Copy link

snahmad commented May 10, 2018

Should we been using io_context instead of io_service in latest boost.

@djarek
Copy link

djarek commented May 10, 2018

io_service is deprecated. Yes, you should use io_context. Beware that the "old" API is deprecated as well (e.g. io_service.post(), you should use post(io_context, handler)).

@superlambchops
Copy link

Is there a guide to converting a program from using io_context to use io_service?

@djarek
Copy link

djarek commented Oct 5, 2018

io_context -> io_service
io_context.post() -> io_context.get_executor().post()
io_context.dispatch() -> io_context.get_executor().dispatch()

io_context::strand -> strand<io_context::executor_type>

there were also changes to composed operation customization hooks - there are only 2 now - boost::asio::associated_allocator and boost::asio::associated_executor, which default to looking for get_allocator(), get_executor(), T::allocator_type, T::executor_type members of the composed operation function object.

This is not a complete list.

@GrumpyOldTroll
Copy link

Is there a doc outlining the reasons a non-backward-compatible change was required? This is an unpleasant surprise, and pretty disruptive to existing projects using boost...

@DinoStray
Copy link

I feel terrible for the changes

@TorstenRobitzki
Copy link

@djarek In your list above, there is one thing missing. In earlier versions of asio, we could obtain the io_context from get_io_service() in serial_port or other IO objects. Now, .get_executor().context() returns the base class to io_context and a downcast is required. Is there an other solution to get the io_context from an existing IO object?

@thejohnfreeman
Copy link

io_context -> io_service
io_context.post() -> io_context.get_executor().post()
io_context.dispatch() -> io_context.get_executor().dispatch()

io_context::strand -> strand<io_context::executor_type>

New user here. Is this supposed to mean "the left expression supersedes the right expression" or "change occurrences of the left expression to the one on the right"?

@ivan-v-kush
Copy link

Is there a doc outlining the reasons a non-backward-compatible change was required? This is an unpleasant surprise, and pretty disruptive to existing projects using boost...

I think due to Network TS. But now appears the question, why the WG have
choosen io_context

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0112r0.html

@ghost
Copy link

ghost commented Dec 30, 2020

This issue was moved by chriskohlhoff to chriskohlhoff/asio#615.

@ghost ghost closed this as completed Dec 30, 2020
@ghost ghost locked and limited conversation to collaborators Dec 30, 2020
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants