I experimented with m_socket->shutdown() instead of close, and it made little difference. In fact, from the documentation it seems shutdown() is the one I definitely don't want to call, as close() is supposed to wait for data to be sent.
This is a common point of confusion with sockets programming. Here is how it works according to my understanding. Note that I know nothing of how boost sockets are implemented, the following applies specifically to the BSD socket interface, which means that by extension it should apply to boost sockets although I can't guarantee that.
1) shutdown() initiates a graceful termination sequence. It never blocks, regardless of the value of SO_LINGER. shutdown() specifically tells the kernel "I'm done, start flushing out any pending data that's left over". But it never frees any underlying O/S resources or handles.
2) close() terminates the connection and frees O/S handles. On windows, the function is called closesocket() and first initiates a shutdown (according to the definition above), if one has not been initiated already. This behavior is not guaranteed as far as I know (someone correct me if I'm wrong) and probably does not happen on O/Ses other than Windows. Even the windows documentation recommends not relying on it. *IF* a graceful shutdown has been initiated *AND* the SO_LINGER option is set, then close() blocks until either a) the linger timeout has expired, or b) all pending data has been sent, whichever comes first.
Therefore, I believe the correct sequence is to first set the SO_LINGER option, then call shutdown, then call close.