-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slave acttivity fix #35
Slave acttivity fix #35
Conversation
This looks like it solves the problems of messages. Can't we just put 'takeOverMessages in the EE API and dynamic cast in SlaveActivity to an ExecutionEngine ? Then we don't need to add this virtual function to ActivityInterface, and we're freed from the 'throw if not implemented' case in Timer. Also, it can then be non-virtual. This is indeed the 'pumping' I was talking about earlier... |
The our_act could be nil if there is a parent task given for execution. In this case our_act->stop() will defnilty fail.
Thank's peter, Only point where i'm not sure is weather i should throw or returning false, if the dynamic casts failing. |
I only use exceptions if there is no means to communicate a failure by the return type. So here I would prefer to return false in trigger() |
Fixed bug in which case operations within Task's were not called anymore if the task is not running, and a slave of another one.
updated |
The patch reverts most of the previous patches applied to fix the issue that `OwnThread` operations 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 #35, with follow-ups in https://github.com/orocos-toolchain/rtt/issue/59, #60 and #71. The `slave_test` added in one of the original PRs 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 patch is 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. Signed-off-by: Johannes Meyer <johannes@intermodalics.eu>
The patch reverts most of the previous patches applied to fix the issue that `OwnThread` operations 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 #35, with follow-ups in https://github.com/orocos-toolchain/rtt/issue/59, #60 and #71. The `slave_test` added in one of the original PRs 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 patch is 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. Signed-off-by: Johannes Meyer <johannes@intermodalics.eu>
This is a new version of the already started request from gitorious:
https://gitorious.org/orocos-toolchain/rtt/commit/da42c1c6336bb69bafbc5ac59a630ba07656e7cc
https://gitorious.org/orocos-toolchain/rtt/merge_requests/25