orocos-toolchain / rtt

Orocos Real-Time Toolkit
http://www.orocos.org
Other
72 stars 79 forks source link

Connect multiple operations #222

Closed ahoarau closed 5 years ago

ahoarau commented 7 years ago

Like the connect in Qt, I think it would be useful to be able to connect an operationCaller to multiple operations.

A provides reset()
B provides reset() # B is a different component

connectServices("A","C")
connectServices("B","C")

C.reset() # calls A.reset() and B.reset()

That would only be allowed for operations that have no return of course.

meyerj commented 7 years ago

Not exactly what you are suggesting, but something alike is possible with signalling operations and signals in general. At least you can have an operation that signals more than one implemented function, or in other words, invokes them one after the other. To my knowledge there is currently no way to connect RTT signals dynamically from scripting, but you could use the mechanism to build something like what you propose yourself:

#include <rtt/Service.hpp>
#include <rtt/TaskContext.hpp>
#include <rtt/Operation.hpp>
#include <rtt/OperationCaller.hpp>

#include <rtt/plugin/ServicePlugin.hpp>

class ResetService : public RTT::Service {
private:
  RTT::Operation<void()> reset_op_;

public:
  ResetService(RTT::TaskContext* owner)
    : RTT::Service("reset", owner),
      reset_op_("signal_connected_peers")
  {
    this->addOperation("connectPeer", &ResetService::connectPeer, this, RTT::ClientThread);
    this->addEventOperation(reset_op_); // or getOwner()->...

    // If connected operations shall be executed the owner's thread instead of being sent,
    // uncomment the following line and replace ::send by ::call below.
    //reset_op_.getOperationCaller()->setThread(RTT::OwnThread, owner->engine());
  }

  bool connectPeer(const std::string &peer_name, const std::string &op_name)
  {
    RTT::TaskContext *peer = getOwner()->getPeer(peer_name);
    if (!peer) return false;
    RTT::OperationCaller<void()> peer_reset(peer->getOperation(op_name), this->getOwner()->engine());
    if (!peer_reset.ready()) return false;

    RTT::Handle handle = reset_op_.signals(boost::bind(&RTT::OperationCaller<void()>::send, peer_reset));
    return handle.connected();
  }
};

ORO_SERVICE_NAMED_PLUGIN(ResetService, "reset_service")

Usage:

$ deployer
.provide reset_service
loadComponent("A", "ComponentThatProvidesAResetOperation")
reset.connectPeer("A", "reset")
reset.signal_connected_peers()

Check https://github.com/orocos-toolchain/rtt/blob/master/rtt/Operation.hpp#L203 and https://orocos-toolchain.github.io/rtt/master/xml/orocos-components-manual.html#corelib-events.

ahoarau commented 7 years ago

@meyerj Thank you for your help. It working as I need, but it does not support component unloading (it's a detail, but a nice-to-have-feature). Here's the trace :

#0  0x0000000000000050 in ?? ()
#1  0x00007ffff7bb6b30 in RTT::internal::LocalOperationCallerImpl<void ()>::send_impl() ()
   from /home/hoarau/isir/orocos-2.9_ws/gnulinux-install/lib/liborocos-ocl-log4cpp-gnulinux.so.2.9
#2  0x00007ffff7bb6e6d in RTT::internal::InvokerImpl<0, void (), RTT::internal::LocalOperationCallerImpl<void ()> >::send() () from /home/hoarau/isir/orocos-2.9_ws/gnulinux-install/lib/liborocos-ocl-log4cpp-gnulinux.so.2.9
#3  0x00007fffdffe80f1 in RTT::internal::InvokerSignature<0, void (), boost::shared_ptr<RTT::base::OperationCallerBase<void ()> > >::send() (this=0x6f6268)
    at /home/hoarau/isir/orocos-2.9_ws/gnulinux-install/include/rtt/internal/InvokerSignature.hpp:86
#4  0x00007fffdfff087b in boost::_mfi::mf0<RTT::SendHandle<void ()>, RTT::internal::InvokerSignature<0, void (), boost::shared_ptr<RTT::base::OperationCallerBase<void ()> > > >::call<RTT::OperationCaller<void ()> >(RTT::OperationCaller<void ()>&, RTT::internal::InvokerSignature<0, void (), boost::shared_ptr<RTT::base::OperationCallerBase<void ()> > > const*) const (this=0x6f6250, u=...) at /usr/include/boost/bind/mem_fn_template.hpp:35
#5  0x00007fffdfff02b9 in boost::_mfi::mf0<RTT::SendHandle<void ()>, RTT::internal::InvokerSignature<0, void (), boost::shared_ptr<RTT::base::OperationCallerBase<void ()> > > >::operator()<RTT::OperationCaller<void ()> >(RTT::OperationCaller<void ()>&) const (this=0x6f6250, u=...) at /usr/include/boost/bind/mem_fn_template.hpp:55
#6  0x00007fffdffef774 in boost::_bi::list1<boost::_bi::value<RTT::OperationCaller<void ()> > >::operator()<RTT::SendHandle<void ()>, boost::_mfi::mf0<RTT::SendHandle<void ()>, RTT::internal::InvokerSignature<0, void (), boost::shared_ptr<RTT::base::OperationCallerBase<void ()> > > >, boost::_bi::list0>(boost::_bi::type<RTT::SendHandle<void ()> >, boost::_mfi::mf0<RTT::SendHandle<void ()>, RTT::internal::InvokerSignature<0, void (), boost::shared_ptr<RTT::base::OperationCallerBase<void ()> > > >&, boost::_bi::list0&, long) (this=0x6f6260, f=..., a=...)
    at /usr/include/boost/bind/bind.hpp:243
#7  0x00007fffdffee829 in boost::_bi::bind_t<RTT::SendHandle<void ()>, boost::_mfi::mf0<RTT::SendHandle<void ()>, RTT::internal::InvokerSignature<0, void (), boost::shared_ptr<RTT::base::OperationCallerBase<void ()> > > >, boost::_bi::list1<boost::_bi::value<RTT::OperationCaller<void ()> > > >::operator()() (this=0x6f6250)
    at /usr/include/boost/bind/bind.hpp:893
#8  0x00007fffdffecfbe in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<RTT::SendHandle<void ()>, boost::_mfi::mf0<RTT::SendHandle<void ()>, RTT::internal::InvokerSignature<0, void (), boost::shared_ptr<RTT::base::OperationCallerBase<void ()> > > >, boost::_bi::list1<boost::_bi::value<RTT::OperationCaller<void ()> > > >, void>::invoke(boost::detail::function::function_buffer&) (function_obj_ptr=...)
    at /usr/include/boost/function/function_template.hpp:159
#9  0x00007ffff7bb3f04 in RTT::internal::signal0<void, boost::function<void ()> >::emitImpl(boost::intrusive_ptr<RTT::internal::ConnectionBase> const&) ()
   from /home/hoarau/isir/orocos-2.9_ws/gnulinux-install/lib/liborocos-ocl-log4cpp-gnulinux.so.2.9
#10 0x00007ffff7b9828e in void RTT::internal::ListLockFree<boost::intrusive_ptr<RTT::internal::ConnectionBase> >::apply<boost::_bi::bind_t<void, void (*)(boost::intrusive_ptr<RTT::internal::ConnectionBase> const&), boost::_bi::list1<boost::arg<1> > > >(boost::_bi::bind_t<void, void (*)(boost::intrusive_ptr<RTT::internal::ConnectionBase> const&), boost::_bi::list1<boost::arg<1> > >) [clone .isra.259] ()
   from /home/hoarau/isir/orocos-2.9_ws/gnulinux-install/lib/liborocos-ocl-log4cpp-gnulinux.so.2.9
#11 0x00007ffff7bb6d63 in RTT::internal::InvokerImpl<0, void (), RTT::internal::LocalOperationCallerImpl<void ()> >::call() () from /home/hoarau/isir/orocos-2.9_ws/gnulinux-install/lib/liborocos-ocl-log4cpp-gnulinux.so.2.9
#12 0x00007ffff7b9f124 in RTT::internal::FusedMCallDataSource<void ()>::evaluate() const ()
   from /home/hoarau/isir/orocos-2.9_ws/gnulinux-install/lib/liborocos-ocl-log4cpp-gnulinux.so.2.9
#13 0x00007ffff792c307 in OCL::TaskBrowser::doPrint(boost::intrusive_ptr<RTT::base::DataSourceBase>, bool) ()
   from /home/hoarau/isir/orocos-2.9_ws/gnulinux-install/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.9
#14 0x00007ffff792d016 in OCL::TaskBrowser::printResult(RTT::base::DataSourceBase*, bool) ()
   from /home/hoarau/isir/orocos-2.9_ws/gnulinux-install/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.9
#15 0x00007ffff7935b0c in OCL::TaskBrowser::evalCommand(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) ()
   from /home/hoarau/isir/orocos-2.9_ws/gnulinux-install/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.9
#16 0x00007ffff793cb9d in OCL::TaskBrowser::loop() ()
   from /home/hoarau/isir/orocos-2.9_ws/gnulinux-install/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.9
#17 0x000000000040fb90 in main ()
meyerj commented 7 years ago

Indeed, but this problem affects all OperationCaller instances, whether they are stored in a signal or not. OperationCaller instances are not notified if the target operation is unloaded and still hold dangling pointers to the operations's implementation and execution engine. It might be possible to switch over to weak pointers in some places in order to catch this case and immediately return a SendFailure or disconnect the caller automatically, but that would definitely be another issue.

A short term extension would be the addition of a disconnectPeer(name) method. The service would have to keep the Handle instances in a map to lookup TaskContext to Handle pairs and call the disconnect() method from disconnectPeer(name). It would be the responsibility of the caller/deployer to disconnect a peer from the service before unloading it.