Contribute! Which weakness have you detected in RTT?


You can edit this page to post your contribution to OrocosRTT 2.0. Please, keep your comment concise and clear: if you want to launch a long debate, you can still use the Developers Forum! Short examples can help other people understanding what you mean.

A) According to the section 4. of the Orocos Component Builder's Manual, the callback of a synchronous event is executed inside the thread of the event's emitter. Imagine that TaskA emits an event, and TaskB, who subscribes synchronously to it, has an handle with a infinite loop: the behavior of TaskA would be jeopardize. Keep in mind that:
  • TaskA hasn't any clue to know what will happen inside the callback of TaskB.
  • It can't prevent TaskB from connecting synchronously.
  • Once blocked, there is nothing it can do.

B) What would happen if a TaskContext is attached to a PeriodicActivity, but internally it was designed to run as a NonPeriodicActivity. What would happen if a sensor with a refresh rate of 10 Hz is read from a Component deployed at 1000 Hz? May be the Activity of the TC should be defined by the TC itself, even if this would mean to have it is hard-coded in the TC.
C) Because of single thread serialization, we can have that a sleep in 1 Task, affect other tasks which are not aware and are not responsible of it. See the source code in the sub page.