Hi list, I'm using the signals2 library in the arrangement shown below. Connections are using the scoped_connection class. When I call Disconnect on an instant of X I expect that it won't be referenced anymore (by the signaller object.) But it generally doesn't seem to be the case. For the object "a" it is correctly destructed but "b" isn't destructed until the signaller object is destructed. I am using signals2 correctly? [Basically, I have a asio socket objects that I want to close when the service is stopped so I'm signaling the objects this way] Thanks, Liam. ------------------------------------------------------------------------------------- #include <iostream> #include <boost/shared_ptr.hpp> #include <boost/signals2.hpp> #include <boost/enable_shared_from_this.hpp> struct X : public boost::enable_shared_from_this<X> { X(std::string S) : s_(S) { std::cout << "X() " << s_ << std::endl; } ~X() { std::cout << "~X() " << s_ << std::endl; } void Signal() { std::cout << "signal " << s_ << std::endl; } void Start(boost::signals2::signal<void ()>& Signaller) { connection_ = Signaller.connect(boost::bind(&X::Signal, shared_from_this())); } void Disconnect() { connection_.disconnect(); //connection_.release(); } std::string s_; boost::signals2::scoped_connection connection_; }; typedef boost::shared_ptr<X> SX; void TestSignals() { boost::signals2::signal<void ()> signaller; //boost::signals2::scoped_connection a, b, c, d; { SX a(new X("a")), b(new X("b")), c(new X("c")), d(new X("d")); a->Start(signaller); a->Disconnect(); b->Start(signaller); c->Start(signaller); b->Disconnect(); } // a's destructor is called but not b's std::cout << "b's destructor should of been called" << std::endl; // std::cout << "->signaller" << std::endl; signaller(); std::cout << "<-signaller" << std::endl; } int main() { TestSignals(); return 0; } ------------------------------------------------------------- output: $ ./Signal X() a X() b X() c X() d ~X() d ~X() a b's destructor should of been called ->signaller ~X() b signal c <-signaller ~X() c ---------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 25 June 2010, liamv7 wrote:
I'm using the signals2 library in the arrangement shown below. Connections are using the scoped_connection class. When I call Disconnect on an instant of X I expect that it won't be referenced anymore (by the signaller object.) But it generally doesn't seem to be the case. For the object "a" it is correctly destructed but "b" isn't destructed until the signaller object is destructed. I am using signals2 correctly?
Disconnect only flags the slot as disconnected, it doesn't immediately destroy the slot object. Slots are cleaned up incrementally during signal invocations and connects. I suppose I should add a FAQ entry about this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkwkoXEACgkQ5vihyNWuA4Wn9gCg5FWyAVVFTxKV4zEgbl8BWlhi ILsAoIm3PAfLHBCy8F1fTxxnsmJ7wSk3 =u4eE -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 25 June 2010, Igor R wrote:
Disconnect only flags the slot as disconnected, it doesn't immediately destroy the slot object. Slots are cleaned up incrementally during signal invocations and connects. I suppose I should add a FAQ entry about this.
By the way, what's the best technique to force this clean-up?
There isn't a way right now. It would require adding a method to signals to do a cleanup, plus a method to wait for any concurrent invocations to complete. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkwkvrMACgkQ5vihyNWuA4VgsgCfX2ubAXb1apK36M0u/XY2Dvr+ wesAn2XidcGN70yqzw82EW2F+upM4Zfm =T9Hs -----END PGP SIGNATURE-----
There isn't a way right now. It would require adding a method to signals to do a cleanup, plus a method to wait for any concurrent invocations to complete.
Why to wait? I mean the following use case: my_slot::conect() { conection_ = asyncSubsystem_.signal_.connect(&listener::handler, smart_ptr_from_this()); } my_slot::disconnect() { conection_.disconnect(); asyncSubsystem_.signal_.cleanup(); } All I want here is that after I call my_slot::disconnect, the my_slot instance (being managed by means of some smart ptr) will die sooner or later.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 25 June 2010, Igor R wrote:
There isn't a way right now. It would require adding a method to signals to do a cleanup, plus a method to wait for any concurrent invocations to complete.
Why to wait?
You wouldn't have to. I'm just assuming people who find it unacceptable to let the signal decide when it needs to destroy the slot object have some reason to need to know that the object has really been destroyed, and not just know that it will probably be destroyed sometime soon.
All I want here is that after I call my_slot::disconnect, the my_slot instance (being managed by means of some smart ptr) will die sooner or later.
It will already die sooner or later, without doing any forced cleanup, assuming the signal is periodically connected to, or invoked, or eventually destroyed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkwkzUEACgkQ5vihyNWuA4UT5QCggusaKzm54lI4Fh6OgIpCBptB LAkAoNZGdZH9fSv8cKALRi+9VJBs4XU5 =Nj+n -----END PGP SIGNATURE-----
It will already die sooner or later, without doing any forced cleanup, assuming the signal is periodically connected to, or invoked, or eventually destroyed.
Well, unfortunately, in my case this assumption is not always correct. Right now I just perform a "fake" connect/disconnect instead of cleanup() in the above pseudocode.
On 26 June 2010 00:30, Frank Mori Hess <frank.hess@nist.gov> wrote:
On Friday 25 June 2010, liamv7 wrote:
I'm using the signals2 library in the arrangement shown below. Connections are using the scoped_connection class. When I call Disconnect on an instant of X I expect that it won't be referenced anymore (by the signaller object.) But it generally doesn't seem to be the case. For the object "a" it is correctly destructed but "b" isn't destructed until the signaller object is destructed. I am using signals2 correctly?
Disconnect only flags the slot as disconnected, it doesn't immediately destroy the slot object. Slots are cleaned up incrementally during signal invocations and connects. I suppose I should add a FAQ entry about this.
Thanks for the info, Frank. The signals (1st version) seems to behave as I want -- destructing on disconnect. So I will try using that.
participants (3)
-
Frank Mori Hess -
Igor R -
liamv7