Hi Rod, Rod Morison <rod@morison.biz> wrote:
Right, that's a nice design, with shared_ptrs. So the socket destructor will call shutdown/close?
Yep, it calls 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?
Good question, I hadn't considered the effects of a linger timeout on the destructor. As it stands, it will block. I think I need to change it so that the destructor sets the linger option back to the default behaviour before calling close. If you really do want a blocking close, then the close() function can be used explicitly.
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?
Yep, exactly. I see it as most useful for applications that need to perform additional socket operations as part of shutdown. For example, an app might need to send messages over a socket to a logging server, etc. Cheers, Chris