Use the pointers instead of reference in loaned interfaces

[saikishor]

Earlier we were using the objects directly instead of the pointers, and that means inorder for the controllers to have access the onyl way is to store the reference to that particular variable

However, In the new approach with the pointers, we cannot have the reference to the internal memory of the pointers, it is dangerous as in previous case that the loaned interfaces have access to data without having the ownership, this means if everyone removes this interface, we will have a dangling interface

[christophfroehlich]

LGTM, thanks for adding the explanation why we should change this.

I was just wondering if we should check the use_count when accessing the handle (if there exists even a hardware with it), but I don't know if this is an expensive operation.

[destogl]

I have here also a question: why is it not also ported to jazzy?

In Jazzy, we faced an issue where we lost some references to handles when trying to access them from JTB. Did you ever encounter this? Can this be related?

[destogl]

@saikishor can you please explain one more time, I am reading this for the 10th time and I am not sure when this can happen. I is important as I think that i happens for us. But I am not sure why.

[saikishor]

I think the right approach here could be a weak_ptr

[destogl]

But when can it happen that we have dangling pointer (reference)?

[saikishor]

But when can it happen that we have dangling pointer (reference)?

It could be that if a controller ends up in error and we have to deactivate it and then the chained controllers will be left with an invalid reference, and the consequence of that is pretty unknown. This won't happen if things are handled properly, but we never know the edge cases.

If everyone wanted to keep it this way, I'm fine too

[mamueluth]

I would also rather use a weak pointer and check if the observed object is still there (command_interface_.lock() before access to the interface) because loaned interfaces do not own but observe the object. By using shared_ptr we increase the reference count and extend live time of the object and i am not sure of the consequences here...

For me it seems like we have more of a lifetime and ownership problem here because a loanedinterfaces should not outlive the interfaces they are created on.

[saikishor]

I would also rather use a weak pointer and check if the observed object is still there (command_interface_.lock() before access to the interface) because loaned interfaces do not own but observe the object. By using shared_ptr we increase the reference count and extend live time of the object and i am not sure of the consequences here...

For me it seems like we have more of a lifetime and ownership problem here because a loanedinterfaces should not outlive the interfaces they are created on.

Yes, I agree with you. Weak_ptr is perfect for this application, but at the same time. I'm worried about the performance costs it might bring. As weak_ptr is lock free but not wait free, so continuous writing to interfaces might cause issues.

I'll see if I can test this on TALOS and see if it causes any jitter or not. This can wait until then