FileDescriptorActivity and new RTT::Activity semantics

On 12/15/2010 03:04 PM, Sylvain Joyeux wrote:
> The FileDescriptorActivity is an activity which triggers when data is
> available on a file descriptor. It assumes that, when calling step(),
> the underlying task (or whatever object that gets triggered) will empty
> the watched FDs. It was fine on RTT1
>
> However, this is not true anymore on RTT2 ! Since, now, RTT::Activity
> runs *all the time*. I.e. if the user adds a watch, the activity will
> loop forever until the component is started.
>
> For the time being, I will require users of the FileDescriptorActivity
> to call watch() in startHook() and clearWatches() in stopHook() (instead
> of configureHook() and cleanupHook()).
>
> In the long run, do you guys see a way to fix this without the user
> having to think about when to call watch/clearWatches ?
Actually, amending my own question, oroGen could take care of calling
clearWatches in stopHook().

The user will still have to call watch()

FileDescriptorActivity and new RTT::Activity semantics

On Wednesday 15 December 2010 15:04:43 Sylvain Joyeux wrote:
> The FileDescriptorActivity is an activity which triggers when data is
> available on a file descriptor. It assumes that, when calling step(),
> the underlying task (or whatever object that gets triggered) will empty
> the watched FDs. It was fine on RTT1
>
> However, this is not true anymore on RTT2 ! Since, now, RTT::Activity
> runs *all the time*. I.e. if the user adds a watch, the activity will
> loop forever until the component is started.
>
> For the time being, I will require users of the FileDescriptorActivity
> to call watch() in startHook() and clearWatches() in stopHook() (instead
> of configureHook() and cleanupHook()).
>
> In the long run, do you guys see a way to fix this without the user
> having to think about when to call watch/clearWatches ?

I don't understand how this is supposed to work well enough to answer this
question. What you could do is check in the FDA if the pointer to the runner
object is a TaskContext* and check its status to decide what to do in your
activity object. Since FDA already assumes a certain behaviour of the object
it is running, I don't see much harm in adding this extra coupling.

Peter