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 ;-)