Re: [boost] [Asio] How do i code a resource clean server shutdown?

From: Rod Morison (rod_at_[hidden])
Date: 2006-08-18 01:14:41

Christopher Kohlhoff wrote:
>
> The first involves forcing io_service::run() to exit by calling
> io_service::interrupt(). As you say, this means that there will
> still be work pending. However, the io_service destructor causes
> all copies of user-defined handlers to be destroyed. If you
> follow the daytime server example of using shared_ptrs to manage
> your object lifetimes, these objects will all be cleaned up
> automatically.
>
>   
Right, that's a nice design, with shared_ptrs. So the socket destructor 
will call shutdown/close? What if I have a linger timeout set on the 
socket, the destructor can't hang on that, can it? Or does it work 
differently than I'm thinking?

I just need to make sure I know how to open and close lots of sockets, 
like thousands per second, and that a resource leak (socket handles, 
usually) isn't going to max out a kernel table.

> The second approach is to cancel the asynchronous operations by
> explicitly closing all the sockets and acceptor. The operations
> will all complete with the operation_aborted error, and provided
> you don't start any new async operations the io_service::run()
> function will exit due to lack of work. See the HTTP server
> program for an example of this approach.
>
>   
So this approach lets me explicity handle shutdowns...at the cost of 
having to keep track of those sockets instead of letting shared ptrs 
within the io_service destructor do the bookkeeping for me, right?
>> - I can close the tcp::acceptor in tcp_server, but what about
>> the socket that's listening on it?
>>     
>
> If you're referring to the peer socket that is being "accepted",
> you don't need to do anything with it. The asynchronous accept
> operation is "owned" by the acceptor, so closing the acceptor is
> sufficient to abort the operation. No resource is assigned to
> the peer socket unless the accept is successful.
>   
What I meant (in Daytime.3) was the acceptor handler (handle_accept) 
owns a tcp_connection, which owns a socket. But, I see that shared ptrs 
take care of that business.

Thanks for letting me pelt you with these questions. It makes the 
difference between getting this app right the second time vs the 3rd or 
4th ;-)