2012/4/4 g ah <gaohml [..] ...>:
>
> Peter Soetens wrote:
>> 2012/4/3 g ah <gaohml [..] ...>:
>>> Hi,
>>>
>>> If I wanted to guarantee that no writes to ports could ever be 'lost' on the receiving sides, due to buffer overflows for instance, am I correct in thinking that this could only be done using slave activities or synchronous operations?
>>
>> Exactly.
>>
>>> The slave activities could all run (and thus read their ports) before the master can push new data, preventing overruns. The operations could be 'chained', almost mimicking master-slave relationships.
>>>
>>> Or am I way off?
>>
>> No you're right on. Probably you're inspired by Markus' recent FBSched
>> component ? In this case, you can also connect the ports between these
>> scheduled components using the 'UNSYNC' connection policy for maximum
>> efficiency. If any asynchronous components also needs the communicated
>> data, that component needs to be connected using the regular
>> connection policies (lock-free or locked).
>>
>> You don't *need* to use the SlaveActivity, you could also think up an
>> operation (ClientThread) of your own and call that one instead. iTaSC
>> does this for example to schedule certain computations in components.
>
> yes, that's what I meant with the 'or synchronous operations' bit. Basically add some sort of trigger op, say 'processSample' or something more specific, which first processes then writes data to an output port, then chains to the next component.
>
> As I said earlier, total beginner here, but can the 'chain' be set up using scripting only? I'll RTFM if this is covered elsewhere.

Yes both Lua and classical RTT scripting can do this.

>
> About the slave activities: slaves do really need to subclass SlaveActivity right? No way to somehow transmogrify a normal component (TaskContext subclass) into one?

No, we install an acitivity with task->setActivity( ... ) at runtime.
The deployer does this for you, from scripting. See the deployment
manuals.

Peter