[asio] Removing server socket from service
I have one thread how runs io_service. I have 2 servers (tcp) ports with all corresponded acceptor and bunch of sockets connected to both ports. I am looking into the way to stop just one server but still run the other one. I have implemented a "hard" way to stop server: remove acceptor, cancel/close sockets, that will trigger all read/write asynchronous callbacks, wait till they all done. but there is a incontinence I need to know how may callbacks still here. Is there any simpler way to do the same thing? Something like block the cancel call until all call back done? Please follow the attached hyperlink to an important disclosure: http://www.credit-suisse.com/legal/marketcommentary =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
I have one thread how runs io_service. I have 2 servers (tcp) ports with all corresponded acceptor and bunch of sockets connected to both ports.
I am looking into the way to stop just one server but still run the other one. I have implemented a "hard" way to stop server: remove acceptor, cancel/close sockets, that will trigger all read/write asynchronous callbacks, wait till they all done.
It seems to be the coorect way, but why do you have to wait? Can't you just close sockets/acceptors and forget about them?
Yes I tried that. But at my code async operations got triggered with errors from io_service thread and the acceptor objects was destroyed already. Please follow the attached hyperlink to an important disclosure: http://www.credit-suisse.com/legal/marketcommentary -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Igor R Sent: Wednesday, November 03, 2010 1:40 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [asio] Removing server socket from service
I have one thread how runs io_service. I have 2 servers (tcp) ports with all corresponded acceptor and bunch of sockets connected to both ports.
I am looking into the way to stop just one server but still run the other one. I have implemented a "hard" way to stop server: remove acceptor, cancel/close sockets, that will trigger all read/write asynchronous callbacks, wait till they all done.
It seems to be the coorect way, but why do you have to wait? Can't you just close sockets/acceptors and forget about them? _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
Yes I tried that. But at my code async operations got triggered with errors from io_service thread and the acceptor objects was destroyed already.
When you use async. approach, the best way to manage your objects lifetime is to use shared_from_this idiom, just like in asio examples. This way you ensure that your completion handlers never "hit" destroyed objects.
Am 02.11.2010 22:38, schrieb Sakharuk, Vladimir:
I have one thread how runs io_service. I have 2 servers (tcp) ports with all corresponded acceptor and bunch of sockets connected to both ports.
I am looking into the way to stop just one server but still run the other one. I have implemented a "hard" way to stop server: remove acceptor, cancel/close sockets, that will trigger all read/write asynchronous callbacks, wait till they all done.
Hi, this could be done much easier: - First use shared_from_this() for your client-connections - Let the main-server emit a close-signal, to which the clients connect (don't forget to disconnect on destruction) Example: class server { public: void on_connect() { shared_ptr<client> client = new client(); //you will have to construct this prior to this (to get the soccet for accept()) client->set_close_signal(signal_close_.connect(&client::close, client); client->start(); } void close() { socket_.close(); signal_close_(); } private: signals2::connection signal_close_; tcp::acceptor socket_; }; class client : public enable_shared_from_this<client> { public: void start() {} //start the client using shared_from_this() void set_close_signal(signals2::connection conn) { conn_ = conn; //well... never tried this, look into the signals2-docs } void close() { socket_.close(); } private: tcp::socket socket_; signals2::scoped_connection conn_; //I think that's the name }; The scoped_connection is used to disconnect the close-signal on client-destruction (obvious, I think..) Regards, michi7x7 PS: Note that there might still be client-connections left on close()-call, but there should be no async-action executed because error is set. PPS: Use weak_ptr to store a list of clients in the server
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 03 November 2010, michi7x7 wrote:
shared_ptr<client> client = new client(); //you will have to construct this prior to this (to get the soccet for accept()) client->set_close_signal(signal_close_.connect(&client::close, client);
The scoped_connection is used to disconnect the close-signal on client-destruction (obvious, I think..)
Since you are binding a copy of the shared_ptr<client> into the slot, I don't see how the client could ever get destructed while the connection is still alive. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkzRsicACgkQ5vihyNWuA4XpggCgy7ZZi45s6dHaDR9xbncJTqo/ ncMAn0uh4n4b54hNGdkVFRQkbQGYA2Li =MFrS -----END PGP SIGNATURE-----
Am 03.11.2010 20:04, schrieb Frank Mori Hess:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday 03 November 2010, michi7x7 wrote:
shared_ptr<client> client = new client(); //you will have to construct this prior to this (to get the soccet for accept()) client->set_close_signal(signal_close_.connect(&client::close, client);
Since you are binding a copy of the shared_ptr<client> into the slot, I don't see how the client could ever get destructed while the connection is still alive. Oh damn,
of course you are right. I meant to use the raw-pointer there: client->set_close_signal(signal_close_.connect(&client::close, get_pointer(client)); Regards, michi7x7
participants (4)
-
Frank Mori Hess -
Igor R -
michi7x7 -
Sakharuk, Vladimir