The new solution to the original problem is much less intrusive: Instead of forwarding the operations calls itself and making the ExecutionEngine aware of the existence of masters and slaves, the SlaveActivity that gets triggered (e.g. as a consequence of an operation call) enqueues a message in the master's ExecutionEngine that processes the triggers in the slave's ExecutionEngine work(Trigger) callback, which then processes all the pending messages (and port callbacks) of the slave. This also works across multiple levels of master/slave relations. The difference to the previous solutions is that the pending messages are still enqueued in the engine of the actual runner and explicit calls to Slave.update() from the master thread will also process the pending operations of the slave - but not of the master itself.
The work(Trigger) callback was only introduced in #91 and not yet available back in 2014. Without, it would not be possible to selectively process asynchronous messages of the slave without also triggering synchronous processing steps like updateHook(). In general, since #91 operations and event port callbacks are executed asynchronously, as part of the callback step, while before they were only executed through a full (periodic or non-periodic) update step.
@goldhoorn As the original reporter and author of the first proposed solution in #35, and in case you are still using RTT, could you please test this alternative approach for your application(s)?
The patch reverts most of the previous patches applied to the
ExecutionEngineto fix the issue thatOwnThreadoperations provided by components running in a SlaveActivity have only been executed when the slave was updated, but never asynchronously like for normal activities. This caused dead-locks in certain situations when calling operations of slaves that are never updated before the call returns. The history of the reverted patches started with https://github.com/orocos-toolchain/rtt/pull/35, with follow-ups in https://github.com/orocos-toolchain/rtt/issues/59, https://github.com/orocos-toolchain/rtt/pull/60 and https://github.com/orocos-toolchain/rtt/pull/71.The
slave_testadded in https://github.com/orocos-toolchain/rtt/pull/71/files#diff-926cb9fdc506c3abaed334876a3402a5 was not reverted and still succeeds with the new patch.The new solution to the original problem is much less intrusive: Instead of forwarding the operations calls itself and making the ExecutionEngine aware of the existence of masters and slaves, the SlaveActivity that gets triggered (e.g. as a consequence of an operation call) enqueues a message in the master's ExecutionEngine that processes the triggers in the slave's ExecutionEngine
work(Trigger)callback, which then processes all the pending messages (and port callbacks) of the slave. This also works across multiple levels of master/slave relations. The difference to the previous solutions is that the pending messages are still enqueued in the engine of the actual runner and explicit calls toSlave.update()from the master thread will also process the pending operations of the slave - but not of the master itself.The
work(Trigger)callback was only introduced in #91 and not yet available back in 2014. Without, it would not be possible to selectively process asynchronous messages of the slave without also triggering synchronous processing steps likeupdateHook(). In general, since #91 operations and event port callbacks are executed asynchronously, as part of the callback step, while before they were only executed through a full (periodic or non-periodic) update step.@goldhoorn As the original reporter and author of the first proposed solution in #35, and in case you are still using RTT, could you please test this alternative approach for your application(s)?