i making few attempts @ making own simple asynch tcp server using boost::asio after not having touched several years.
the latest example listing can find is: http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/tutorial/tutdaytime3/src.html
the problem have example listing (i feel) cheats , cheats big, making tcp_connection shared_ptr, such doesn't worry lifetime management of each connection. (i think) brevity, since small tutorial, solution not real world.
what if wanted send message each client on timer, or similar? collection of client connections going necessary in real world non-trivial server.
i worried lifetime management of each connection. figure natural thing keep collection of tcp_connection objects or pointers them inside tcp_server. adding collection onconnect callback , removing collection ondisconnect.
note ondisconnect called actual disconnect method, in turn called onreceive callback or onsend callback, in case of error.
well, therein lies problem.
consider we'd have callstack looked this:
tcp_connection::~tcp_connection tcp_server::ondisconnect tcp_connection::ondisconnect tcp_connection::disconnect tcp_connection::onreceive this cause errors call stack unwinds , executing code in object has had destructor called...i think, right?
i imagine doing server programming comes across scenario in fashion. strategy handling it?
i hope explanation enough follow. if not let me know , create own source listing, large.
edit: related
) memory management in asynchronous c++ code
imo not acceptable answer, relies on cheating shared_ptr outstanding on receive calls , nothing more, , not real world. if server wanted "hi" clients every 5 minutes. collection of kind necessary. if calling io_service.run on multiple threads?
i asking on boost mailing list: http://boost.2283326.n4.nabble.com/how-to-design-proper-release-of-a-boost-asio-socket-or-wrapper-thereof-td4693442.html
while others have answered second half of answer, seems complete answer can find, came asking same question on boost mailing list.
i summarize here in order assist arrive here search in future.
there 2 options
1) close socket in order cancel outstanding io , post callback post-disconnection logic on io_service , let server class called when socket has been disconnected. can safely release connection. long there 1 thread had called io_service::run, other asynchronous operations have been been resolved when callback made. however, if there multiple threads had called io_service::run, not safe.
2) others have been pointing out in answers, using shared_ptr manage connections lifetime, using outstanding io operations keep them alive, viable. can use collection weak_ptr connections in order access them if need to. latter tidbit had been omitted other posts on topic confused me.
Comments
Post a Comment