|
Boost : |
From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-08-18 01:43:37
Hi Rod,
Rod Morison <rod_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk