During the RTT2 development, I remember Peter mentioning a way to
initialize a connection with a default sample.
I thought I could use this mechanism to use std::vector in a RT-safe
way, i.e.:
* have the std::vector be always of a fixed size (i.e. I will always
push 4 elements on the same port of the same component)
* resize() it before startHook()
* have RTT initialize the connections properly with a sample I provide
However, I don't find any API that allows me to do the last point. Do I
miss something ?
Sylvain
std::vector, real-timeness and data_sample
Hi Sylvain,
In the Orocos Component Builder Manual, Section 3.3.3 “Guaranteeing
Real-Time data flow” :
Philippe
2010/11/24 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> During the RTT2 development, I remember Peter mentioning a way to
> initialize a connection with a default sample.
>
> I thought I could use this mechanism to use std::vector in a RT-safe
> way, i.e.:
> * have the std::vector be always of a fixed size (i.e. I will always
> push 4 elements on the same port of the same component)
> * resize() it before startHook()
> * have RTT initialize the connections properly with a sample I provide
>
> However, I don't find any API that allows me to do the last point. Do I
> miss something ?
>
> Sylvain
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
std::vector, real-timeness and data_sample
On 11/24/2010 03:43 PM, Philippe Hamelin wrote:
> Hi Sylvain,
>
> In the Orocos Component Builder Manual, Section 3.3.3 “Guaranteeing
> Real-Time data flow” :
>
>
This is true only for connections created before setDataSample has been
created. New connections don't get that behaviour.
But since it is in the documentation, I assume that case has been
forgotten ...
std::vector, real-timeness and data_sample
On Wednesday 24 November 2010 15:59:30 Sylvain Joyeux wrote:
> On 11/24/2010 03:43 PM, Philippe Hamelin wrote:
> > Hi Sylvain,
> >
> > In the Orocos Component Builder Manual, Section 3.3.3 “Guaranteeing
> > Real-Time data flow” :
> >
> >
>
> This is true only for connections created before setDataSample has been
> created. New connections don't get that behaviour.
They do. setDataSample may be called at any time (before/after) connection
creation. It will initialize the current and future connections.
Peter
std::vector, real-timeness and data_sample
On 11/24/2010 04:39 PM, Peter Soetens wrote:
>> This is true only for connections created before setDataSample has been
>> created. New connections don't get that behaviour.
>
> They do. setDataSample may be called at any time (before/after) connection
> creation. It will initialize the current and future connections.
Got it. You initialize the connections with the last written value if it
is kept. And setDataSample does turn keepLastWrittenValue on ..
This is a very important "detail" that should be documented. Once you
have called setDataSample(), keepLastWrittenValue is turned on and the
connection will be setup using the last written sample, which may not be
the sample given to setDataSample.
std::vector, real-timeness and data_sample
On Wednesday 24 November 2010 17:36:01 Sylvain Joyeux wrote:
> On 11/24/2010 04:39 PM, Peter Soetens wrote:
> >> This is true only for connections created before setDataSample has been
> >> created. New connections don't get that behaviour.
> >
> > They do. setDataSample may be called at any time (before/after)
> > connection creation. It will initialize the current and future
> > connections.
>
> Got it. You initialize the connections with the last written value if it
> is kept. And setDataSample does turn keepLastWrittenValue on ..
A necessity, I had to store it somewhere for future connections.
>
> This is a very important "detail" that should be documented. Once you
> have called setDataSample(), keepLastWrittenValue is turned on and the
> connection will be setup using the last written sample, which may not be
> the sample given to setDataSample.
Hmm. You're right, this smells. I incline towards fixing it instead of
documenting it.
Peter
std::vector, real-timeness and data_sample
On 11/24/2010 05:43 PM, Peter Soetens wrote:
> On Wednesday 24 November 2010 17:36:01 Sylvain Joyeux wrote:
>> On 11/24/2010 04:39 PM, Peter Soetens wrote:
>>>> This is true only for connections created before setDataSample has been
>>>> created. New connections don't get that behaviour.
>>>
>>> They do. setDataSample may be called at any time (before/after)
>>> connection creation. It will initialize the current and future
>>> connections.
>>
>> Got it. You initialize the connections with the last written value if it
>> is kept. And setDataSample does turn keepLastWrittenValue on ..
>
> A necessity, I had to store it somewhere for future connections.
>
>>
>> This is a very important "detail" that should be documented. Once you
>> have called setDataSample(), keepLastWrittenValue is turned on and the
>> connection will be setup using the last written sample, which may not be
>> the sample given to setDataSample.
>
> Hmm. You're right, this smells. I incline towards fixing it instead of
> documenting it.
I personally think it is fine, as long as it is documented. In practice,
since this mechanism is primarily meant to avoid memory allocation, the
"last written sample" will have the same function than "the sample given
to setDataSample". Or at least I believe so.
std::vector, real-timeness and data_sample
On Wednesday 24 November 2010 17:46:25 Sylvain Joyeux wrote:
> On 11/24/2010 05:43 PM, Peter Soetens wrote:
> > On Wednesday 24 November 2010 17:36:01 Sylvain Joyeux wrote:
> >> On 11/24/2010 04:39 PM, Peter Soetens wrote:
> >>>> This is true only for connections created before setDataSample has
> >>>> been created. New connections don't get that behaviour.
> >>>
> >>> They do. setDataSample may be called at any time (before/after)
> >>> connection creation. It will initialize the current and future
> >>> connections.
> >>
> >> Got it. You initialize the connections with the last written value if it
> >> is kept. And setDataSample does turn keepLastWrittenValue on ..
> >
> > A necessity, I had to store it somewhere for future connections.
> >
> >> This is a very important "detail" that should be documented. Once you
> >> have called setDataSample(), keepLastWrittenValue is turned on and the
> >> connection will be setup using the last written sample, which may not be
> >> the sample given to setDataSample.
> >
> > Hmm. You're right, this smells. I incline towards fixing it instead of
> > documenting it.
>
> I personally think it is fine, as long as it is documented. In practice,
> since this mechanism is primarily meant to avoid memory allocation, the
> "last written sample" will have the same function than "the sample given
> to setDataSample". Or at least I believe so.
This is actually documented:
keep_last_written_value Defaults to true. You need keep_last_written_value
== true in two cases:
* You're sending dynamically sized objects through this port in real-time. In
that case, you need to write() to this port such an object before a connection
is created. That object will be used to allocate enough data storage in each
there-after created connection. If you would set keep_last_written_value ==
false in this use case, several memory allocations will happen during the
initial writes, after which none will happen anymore.
* You want to have an input to have the last written data available from
before its connection was created, such that it is immediately initialized.
The keep_last_written_value incurs a space overhead of one thread-safe data
storage container. This is about the same size as one extra connection.
http://www.orocos.org/stable/documentation/rtt/v2.x/api/html/classRTT_1_...
Peter
std::vector, real-timeness and data_sample
On 11/24/2010 05:57 PM, Peter Soetens wrote:
> On Wednesday 24 November 2010 17:46:25 Sylvain Joyeux wrote:
>> On 11/24/2010 05:43 PM, Peter Soetens wrote:
>>> On Wednesday 24 November 2010 17:36:01 Sylvain Joyeux wrote:
>>>> On 11/24/2010 04:39 PM, Peter Soetens wrote:
>>>>>> This is true only for connections created before setDataSample has
>>>>>> been created. New connections don't get that behaviour.
>>>>>
>>>>> They do. setDataSample may be called at any time (before/after)
>>>>> connection creation. It will initialize the current and future
>>>>> connections.
>>>>
>>>> Got it. You initialize the connections with the last written value if it
>>>> is kept. And setDataSample does turn keepLastWrittenValue on ..
>>>
>>> A necessity, I had to store it somewhere for future connections.
>>>
>>>> This is a very important "detail" that should be documented. Once you
>>>> have called setDataSample(), keepLastWrittenValue is turned on and the
>>>> connection will be setup using the last written sample, which may not be
>>>> the sample given to setDataSample.
>>>
>>> Hmm. You're right, this smells. I incline towards fixing it instead of
>>> documenting it.
>>
>> I personally think it is fine, as long as it is documented. In practice,
>> since this mechanism is primarily meant to avoid memory allocation, the
>> "last written sample" will have the same function than "the sample given
>> to setDataSample". Or at least I believe so.
>
> This is actually documented:
>
> keep_last_written_value Defaults to true. You need keep_last_written_value
> == true in two cases:
> * You're sending dynamically sized objects through this port in real-time. In
> that case, you need to write() to this port such an object before a connection
> is created. That object will be used to allocate enough data storage in each
> there-after created connection. If you would set keep_last_written_value ==
> false in this use case, several memory allocations will happen during the
> initial writes, after which none will happen anymore.
> * You want to have an input to have the last written data available from
> before its connection was created, such that it is immediately initialized.
> The keep_last_written_value incurs a space overhead of one thread-safe data
> storage container. This is about the same size as one extra connection.
Fair enough ... but it is in the wrong place.
Since the issue is related to setDataSample, it should be mentioned with
setDataSample as well.
But anyway, there was no issue ... Thanks for the help
Sylvain