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 <abrarov@mail.ru> 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/threads.html).
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