On Wed, Jun 18, 2014 at 4:49 PM, Nicholas Yue wrote:

On 18 June 2014 12:59, Bjorn Reese wrote:

...

On 06/18/2014 08:48 PM, Nicholas Yue wrote:

write_msgs_.pop_front();

...

if (!write_msgs_.empty())

Swap these two lines; otherwise you do not write the last message.

Thanks for the heads up.

Does that mean that the examples will example this problem ?

http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio/example/cpp03/chat/...

as it does a pop before checking

Cheers -- Nicholas Yue

AFAIK this isn't a bug in the example code or in your adaption. The implementation does a push_back() before the async_write request, and does a pop_front() when it completes. So its using the std::deque to store the contents of the message during the async operation. The .empty() check is done in the async_write callback in case multiple messages were queued while an async_write was still pending. As for your original question - information was a little sparse, so I will guess that you want the client to write out all of the queued messages and then initiate the socket close. You need a mechanism for delaying a close request until a future point in time. The close() method will have to "post" another method (safe_close perhaps) that only closes the connection if the queue is empty - otherwise safe_close starts yet-another-event to be handled in the future. This other event can be an async timer or an immediate change to a flag that handle_write reads when the queue is empty. I'm not aware of any other implementations. Both of my suggested implementations (timer or flag) have drawbacks, so the particular application has to be considered. Lee

On 23/06/2014 14:25, Nicholas Yue wrote:

On 22/06/14 6:58 PM, Gavin Lambert wrote:

...

Do you want something like an actual chat server where connection close can occur at any arbitrary time unrelated to data transmission, or something more like HTTP/FTP where you know in advance that you want to close the connection immediately following a particular transmit? [...] I am after the latter.

Currently, I call a different handler when I am sending the last message. That handler does a close. My tests so far indicates that it does the close after the last message was sent.

That seems like a reasonable solution to me. (Others include using the same handler but checking a flag or queue that "knows" when the last thing has been sent. But using a separate handler will be the fastest of those.) Although the notes for close() do mention that it would be safest to call shutdown() first. Otherwise there is presumably still a chance that the OS has successfully queued but not actually transmitted the data, and closing the socket might still cancel it.

I would like to hear alternative solution as my approach may not be technically correct and may have problem during high load.

What sort of problems are you anticipating? (There's no substitute for testing, of course.)