I don't really see how this changes things. The handlers which io_service has, has shared_ptrs to the connection so to get rid of the connection I need to get the io_service to call the handler so that the shared_ptr gets destroyed, or am I missing something? "Igor R" wrote in message news:CAPnv1PKBNRTPfXwArj4YyKt1hxKYEP4-cPvtD6yQNZAz8KNG1w@mail.gmail.com...
After you call io_service::stop(), io_service::run() exits as soon as possible. The handlers are not invoked and not cleared, so all the shared_ptr's embedded into these handlers are sill alive. The handlers will be cleared on ~io_service invocation, as documented: http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio/reference/io_servic...
Thank you. I had read that, which is why I mentioned I was not destroying the server. What I want to do is to cap all connections, because say a password has changed. How could I get the io_service to invoke the handlers with a predefined "stop" error?
You can close the relevant sockets, but the handlers won't be called with your custom error code. If I understand your usecase correctly, the right way to go would be to define a state-machine managing your application states, and to communicate between the state-machine and the connection (or some higher level object that encapsulates it). So that, for example, when a password changes, you put the FSM to "unauthenticated" state, and the transition causes the connection to get closed, etc. You can take a look at the examples of Boost.StateChart and Boost.MSM: http://www.boost.org/doc/libs/1_49_0/libs/statechart/doc/tutorial.html http://www.boost.org/doc/libs/1_49_0/libs/msm/doc/HTML/ch03s02.html#d0e334