Thanks Marat, I am clear on the function and intention of stop and reset now, as I said it helps that I have now RTFM. I am not suggesting the handlers receive an error state, rather it is in a case such as this: boost::asio::io_service io_service; io_service.stop(); // add a async read/write etc here boost::system::error_code ec; size_t count = io_service.run(ec); The variable ec now has a success state which I don't think is accurate an accurate representation of what happened when io_service::run is called on a stopped io_service object. What I am suggesting is in a case such as this an error should be set. Thanks Rory On Tue, Dec 13, 2011 at 6:38 PM, Marat Abrarov wrote:

Hi, Rory.

...

Is there a reason io_service::run does not set an appropriate error on the passed boost::system::error_code object when this is encountered? Certainly it seems like an error case and would help circuital circumstances such as my own.

With current behavior of asio::io_service we can continue working with io_service after it was stopped by calling asio::io_service::reset(). It's like pause on io_service. It's not often used feature but it is nice to know that such behavior is possible.

Also note that invocation of handlers is done only within threads that executes asio::io_service::run (run_one, poll, poll_one - http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio/overview/core/threa... ). When io_service switches to the "stopped" state asio::io_service::run have to exit as fast as possible. When io_service is already in the "stopped" state asio::io_service::run have to exit immediately. So if io_service is already in stopped state before any user thread calls asio::io_service::run how can Asio pass "appropriate error" to asynchronous completion handlers?

IMHO, current design of Asio is very clear.

Regards, Marat Abrarov.

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