On 09.09.2013 13:42, Sylvain Joyeux wrote:
> On 09/09/2013 01:03 PM, Matthias Goldhoorn wrote:
>> "Moin moin",
>>
>> What would be needed to add some of the boost shared_pointer structures
>> to rock/rtt?
>> special boost::shared_pointer and boost::weak_pointer?
> You most probably don't want to do that. boost::shared_pointer and
> boost::weak_pointer have bad multi-threading semantics.
maybe stuffing this into the smart_ptr for locking/unlocking?
>
> What do you actually want to achieve ?
>> How is the transport of the smart_ptr currently handled?, what happen if
>> the same object is send twice trough an RTT port over the boarders of a
>> application (or machine) (e.G. CORB//mqueues)?. Is there a tracking of
>> object identification/id? or will be the object simply represented twice
>> on the receiving machine?
> There are no tracking of object identification. If you send the same
> object twice, you'll get it twice.
That's What i thought already.
>
> Again, what is the actual situation / use case / problem you are trying
> to solve ?
The use case is a library which hardly uses these structures for
internal handing (lists/vectors of 3D Point-cloud data).
Pointcloude -> segmentation -> feature extraction -> post processing
(and in between often visualization).
The plan was to add rock between the -> for
transport/replay/debugging/modularization. To be as compatible to the
original library implementation it would be nice to have support for the
mentioned data-structures.

>

On 09/09/2013 01:54 PM, Matthias Goldhoorn wrote:
> On 09.09.2013 13:42, Sylvain Joyeux wrote:
>> On 09/09/2013 01:03 PM, Matthias Goldhoorn wrote:
>>> "Moin moin",
>>>
>>> What would be needed to add some of the boost shared_pointer structures
>>> to rock/rtt?
>>> special boost::shared_pointer and boost::weak_pointer?
>> You most probably don't want to do that. boost::shared_pointer and
>> boost::weak_pointer have bad multi-threading semantics.
> maybe stuffing this into the smart_ptr for locking/unlocking?
Eh ???
>> Again, what is the actual situation / use case / problem you are trying
>> to solve ?
> The use case is a library which hardly uses these structures for
> internal handing (lists/vectors of 3D Point-cloud data).
> Pointcloude -> segmentation -> feature extraction -> post processing
> (and in between often visualization).
> The plan was to add rock between the -> for
> transport/replay/debugging/modularization. To be as compatible to the
> original library implementation it would be nice to have support for
> the mentioned data-structures.
"Because the library uses it" is hardly a good enough reason. Unless
there is more, use ro_ptr for transport which *has* good multi-threading
semantics. In principle, it was designed for being efficient at
pipelining, unfortunately RTT2.0 introduced OLD_DATA *with* saving the
old sample which made the optimization useless ... We can discuss how to
make it disappear (by e.g. introducing a new policy type in which the
old data sample is not saved)

In any case:
- adding locking in shared_ptr makes no sense if you are distributing
the processing (because no two components would run at the same time).
ro_ptr does.
- if you serialize the processing (by e.g. using the fbsched), ro_ptr
is as good as smart_ptr