Re: [Boost-users] How to design proper release of a boost::asio socket or wrapper thereof

Subject: Re: [Boost-users] How to design proper release of a boost::asio socket or wrapper thereof
From: Christopher Pisz (christopherpisz_at_[hidden])
Date: 2017-04-05 22:14:25

Using shared_ptr is absolutely cheating. I do not think it is real world at
all to maintain a connection's lifetime through the use of outstanding
receive calls.

A simple scenario as to why it is cheating is:
What if the server wants to send "Hello" to all clients every 5 minutes?
You need a collection. If you have a collection, then you maintain a
reference count when using shared_ptrs, and just killed the tutorials
lifetime management scheme. In the end, you need to know when it is safe to
remove the connection from a collection and destroy it.

If I post disconnect, then I am guaranteed no other outstanding IO operation
is in progress for that connection. That's a step in the right direction.
Only if I have one and only one thread that called io_service.run, but then
I still have to know, "when is it safe to destroy my connection object?"

Let's say I posted a callback to tcp_server::Disconnect(tcp_connection *
connection) from tcp_connection::OnReceive. Is it safe for me then to delete
tcp_connection in the body and therefore the socket as well? Will no
"cancel" notifications be called back afterward when tcp_server::Disconnect
then calls close() on the socket? Or should I call close() back in OnReceive
and post a callback to tcp_server::OnDisconnect, which simply deletes the
connection object?

I think the latter might make sense. I will make an attempt at this in code.
Meanwhile a little more clarification on the order of events there might
help. Thanks!

--
View this message in context: http://boost.2283326.n4.nabble.com/How-to-design-proper-release-of-a-boost-asio-socket-or-wrapper-thereof-tp4693442p4693445.html
Sent from the Boost - Users mailing list archive at Nabble.com.