Re: [Boost-users] [asio] Connection not ending

Subject: Re: [Boost-users] [asio] Connection not ending
From: Markus Bonk (markus_bonk_at_[hidden])
Date: 2012-05-10 08:37:24

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_at_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_service/_io_service.html

> 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