Re: [Boost-users] Mixing signals2 and asio mechanism failing

Subject: Re: [Boost-users] Mixing signals2 and asio mechanism failing
From: ustulation (ustulation_at_[hidden])
Date: 2013-10-22 12:56:05

oh i see. I did the same thing myself instead of using track_foreign. In my
case the signal is a private member of a class so it's not directly
accessible at the site which wants to register a callback. Instead the
class with the signal has function exposed so i wonder if using track would
be possible. I did something like this:

boost::signals2::connection ClassWithSignal::registerListener(const
std::function< void() > &refListener)
{
return m_signal.connect(refListener);
}

void SomeListenerClass::funct()
{
std::weak_ptr< SomeListenerClass > weakSelf = shared_from_this();
classWithSignal->registerListener(
[weakSelf]{auto self = weakSelf.lock(); if(self) { self->myCallback(); }}
);
}

i did a few alpha test cases and seemed to pass thread safety issues. I
guess this should work.

I did not read into track() too much because i thought the
registerListener(..) definition above does not permit it, but i don't know
if that's true.

BR//

On Tue, Oct 22, 2013 at 12:07 AM, Scott Mueller [via Boost] <
ml-node+s2283326n4653459h27_at_[hidden]> wrote:

> On Saturday, October 19, 2013 2:47 PM, ustulation wrote:
>
> >I've the following:
> >
> ><1> a single instance of io_service object with a program life-time and
> several threads calling it's run() method. io_service::work is given to it
> so >that it never terminates (unless we stop it).
> >
> ><2> class A which has   boost::signals2::signal connecting functions for
> >callback. * async operations (eg., async_read_until, async_write etc)
> >
> ><3> class B which   is derived from std::shared_from_this ; * has a
> >composition of class A as std::unique_ptr  which is instantiated in B's
> constructor ; <c> has functions/listeners which are registered with signals
> >of class A (eg., signals2::connection connectionObj =
> >uniqPtrA->someSig.connect([=]{shared_from_this_ptrB->listenerFuncOfB();}
> >uniqPtrA->);
> >
> ><4> Another thread outside the thread-pool of <1> above which
> instantiates
> >(and manages) class B:
> >auto ptrB = std::make_shared(); //and further operations.
> >
> >The problem is when I need to destroy ptrB I can't. For instance, i call
> >some method of class B on ptrB to clear all connections it has with class
> A
> >and allow ptrB to go out of scope, but class B destructor is never
> called:
> >
> >{//local scope
> >auto ptrB = std::make_shared();
> >ptrB->connectListenersToA();
> >/* eg auto self = shared_from_this(); connectionObj =
> >uniqPtrA->someSig.connect([=]{self ->listenerFuncOfB();}); referring to
> <3>
> >above */
> >//... do some operations
> >ptrB->disconnectListenersWithA(); //eg connectionObj.disconnect();
> referring
> >to <3> above
> >}//Scope ends I want ptrB to destroy the underlying pointer.
> >
> >The ptrB destructor is never called because
> signals2::connection::disconnect
> >does not seem to wipe out the given slot so the shared_ptr reference of B
> >remains with the signal in class A as anonymous functor (due to lambda in
> ><3> above) containing it does not get destroyed.
> >
> >How do I achieve this?
>
> Have you tried to use track_foreign so that boost uses the weak reference
> of your shared_ptr as an analogue for your connection object? You can even
> do this with std::shared_ptr, instead of boost::shared_ptr<>, since the
> traits specializations are in place (with a properly configured
> environment). Then your connect call looks like this:
> //ptrB->connectListenersToA();
> // would do something like this
> uniqPtrA->someSig.connect(&B::listenerFuncOfB,
> this).track_foreign(shared_from_this());
>
> If you do all of this, then you can just cut your shared_ptrs free and
> they'll get destroyed. Signals2 will store a weak_ptr instead, and get rid
> of that some time afterward.
>
> Best regards,
>
> M. Scott Mueller
> _______________________________________________
> Boost-users mailing list
> [hidden email] <http://user/SendEmail.jtp?type=node&node=4653459&i=0>
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://boost.2283326.n4.nabble.com/Mixing-signals2-and-asio-mechanism-failing-tp4653392p4653459.html
>  To unsubscribe from Mixing signals2 and asio mechanism failing, click
> here<http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4653392&code=dXN0dWxhdGlvbkBnbWFpbC5jb218NDY1MzM5MnwtMTc0MzU1MDY5>
> .
> NAML<http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>

-- 
------------
spandan sharma
--
View this message in context: http://boost.2283326.n4.nabble.com/Mixing-signals2-and-asio-mechanism-failing-tp4653392p4653514.html
Sent from the Boost - Users mailing list archive at Nabble.com.