One issue with the FileDescriptorActivity (FDA) implementation in both RTT v1 and v2, is that it always returns a zero (0.0) period. If the FDA is actually signalled from, for example, a periodic hardware signal, then this is somewhat incorrect. It also makes a component less re-usable if the component requires a periodic activity, as it can't be deployed with an FDA (as the 0.0 period makes it look non-periodic).
We modified the FDA implementation to leave the underlying "actual" period as 0.0, but then to store and return an "intended" period. This can be set by the deployer as with the period of any other periodic activity, to indicate to the underlying component implementation that this is actually intended to be a periodic component. In our case, the underlying component can distinguish between the signalled wake up and a timeout, so that isn't a problem.
I wanted to run this by the ML to see whether anyone had any comments or issues? The patch is attached and is pretty straight forward. This is also in the file-descriptor-activity-fixes branch of my gitorious RTT clone, if that's easier.
Cheers
S
FileDescriptorActivity has a 0.0 period
On Feb 24, 2014, at 18:31 , S Roderick <kiwi [dot] net [..] ...> wrote:
> One issue with the FileDescriptorActivity (FDA) implementation in both RTT v1 and v2, is that it always returns a zero (0.0) period. If the FDA is actually signalled from, for example, a periodic hardware signal, then this is somewhat incorrect. It also makes a component less re-usable if the component requires a periodic activity, as it can't be deployed with an FDA (as the 0.0 period makes it look non-periodic).
>
> We modified the FDA implementation to leave the underlying "actual" period as 0.0, but then to store and return an "intended" period. This can be set by the deployer as with the period of any other periodic activity, to indicate to the underlying component implementation that this is actually intended to be a periodic component. In our case, the underlying component can distinguish between the signalled wake up and a timeout, so that isn't a problem.
>
> I wanted to run this by the ML to see whether anyone had any comments or issues? The patch is attached and is pretty straight forward. This is also in the file-descriptor-activity-fixes branch of my gitorious RTT clone, if that's easier.
>
> Cheers
> S
With the attachment this time - thanks Willy.
S
FileDescriptorActivity has a 0.0 period
Hi Stephen,
On Tue, Feb 25, 2014 at 12:37 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Feb 24, 2014, at 18:31 , S Roderick <kiwi [dot] net [..] ...> wrote:
>
>> One issue with the FileDescriptorActivity (FDA) implementation in both RTT v1 and v2, is that it always returns a zero (0.0) period. If the FDA is actually signalled from, for example, a periodic hardware signal, then this is somewhat incorrect. It also makes a component less re-usable if the component requires a periodic activity, as it can't be deployed with an FDA (as the 0.0 period makes it look non-periodic).
>>
>> We modified the FDA implementation to leave the underlying "actual" period as 0.0, but then to store and return an "intended" period. This can be set by the deployer as with the period of any other periodic activity, to indicate to the underlying component implementation that this is actually intended to be a periodic component. In our case, the underlying component can distinguish between the signalled wake up and a timeout, so that isn't a problem.
>>
>> I wanted to run this by the ML to see whether anyone had any comments or issues? The patch is attached and is pretty straight forward. This is also in the file-descriptor-activity-fixes branch of my gitorious RTT clone, if that's easier.
All your FDA patches look clean to me. Why didn't you add a timeout
Property to the OCL deployment XML ? How is the timeout set now ?
Peter
FileDescriptorActivity has a 0.0 period
On Mar 6, 2014, at 15:24 , Peter Soetens <peter [..] ...> wrote:
> Hi Stephen,
>
> On Tue, Feb 25, 2014 at 12:37 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>> On Feb 24, 2014, at 18:31 , S Roderick <kiwi [dot] net [..] ...> wrote:
>>
>>> One issue with the FileDescriptorActivity (FDA) implementation in both RTT v1 and v2, is that it always returns a zero (0.0) period. If the FDA is actually signalled from, for example, a periodic hardware signal, then this is somewhat incorrect. It also makes a component less re-usable if the component requires a periodic activity, as it can't be deployed with an FDA (as the 0.0 period makes it look non-periodic).
>>>
>>> We modified the FDA implementation to leave the underlying "actual" period as 0.0, but then to store and return an "intended" period. This can be set by the deployer as with the period of any other periodic activity, to indicate to the underlying component implementation that this is actually intended to be a periodic component. In our case, the underlying component can distinguish between the signalled wake up and a timeout, so that isn't a problem.
>>>
>>> I wanted to run this by the ML to see whether anyone had any comments or issues? The patch is attached and is pretty straight forward. This is also in the file-descriptor-activity-fixes branch of my gitorious RTT clone, if that's easier.
>
> All your FDA patches look clean to me. Why didn't you add a timeout
> Property to the OCL deployment XML ? How is the timeout set now ?
>
> Peter
Excellent, thanks.
The timeout is internally set by the implementation in C++, though we've just run into a case where a timeout property would be useful. Probably something we'll add and send back to the community at a later date.
S