[WIP] Add setExternal in ManagedBytes #1582

Nicogene · 2018-03-09T17:34:48Z

This PR add setExternal methods in yarp::os::ManagedBytes for the future class VectorMap.
⚠️ wait #1657 befor merging

Please review code.

drdanz · 2018-03-09T19:01:50Z

src/libYARP_sig/include/yarp/sig/Vector.h

    * Read vector from a connection.
-    * return true iff a vector was read correctly


https://en.wikipedia.org/wiki/Iff

drdanz · 2018-03-09T19:17:48Z

src/libYARP_OS/src/ManagedBytes.cpp

+void ManagedBytes::setExternal(const char *extData, size_t len)
+{
+    if (!extData)
+    {


Please use the style used in the rest of the code if (...) {

drdanz · 2018-03-09T19:20:45Z

src/libYARP_sig/include/yarp/sig/Vector.h

+     * @param extData, pointer to the external data.
+     * @param len, num of elements of the external vector
+     */
+    void setExternal (const char* extData, size_t len)


Extra space after the function name

drdanz · 2018-03-09T19:26:24Z

src/libYARP_OS/src/ManagedBytes.cpp

+    }
+    clear();
+    owned = false;
+    Bytes extb(const_cast<char*>(extData), len);


I was wondering why setExternal accepts const and if this is safe...
The Bytes b is not const, therefore the const char can be modified later by the user by using Vector methods.

This may be actually the trieckiest part of this PR. The Vector does not check if it owns the memory (with e.g. a bool owned like ManagedBytes) and in fact it should not do it. We must understand whether there is a risk of memory modification or not when the memory is not owned.

claudiofantacci · 2018-03-09T23:21:40Z

May you also please the extra spaces in ManagedBytes::operator=()?

claudiofantacci · 2018-03-09T23:22:15Z

src/libYARP_OS/src/ManagedBytes.cpp

+    }
+    clear();
+    owned = false;
+    Bytes extb(const_cast<char*>(extData), len);


This may be actually the trieckiest part of this PR. The Vector does not check if it owns the memory (with e.g. a bool owned like ManagedBytes) and in fact it should not do it. We must understand whether there is a risk of memory modification or not when the memory is not owned.

traversaro

What happens if in an "external" vector the resize method is called? Note that this will happen also when a vector of dimension different from the current one is read in the read method.

In general, what is the rationale for this change?

If we need a Vector with external buffer semantics, why do not define a new class VectorView with this semantics, to make it clear at the type level if the used Vector is owning its own memory or not?
As this new class should not use any dynamic memory allocation, then it could be doable to create a VectorView on the fly from a yarp;:sig::Vector or for any other kind of C++ vector (std::vector<double>, std::array<double, ..>, Eigen::MatrixXd) similar (but simpler) to how the Eigen::Map class works (https://eigen.tuxfamily.org/dox/group__TutorialMapClass.html).

Note: the name VectorView is inspired from the std::string_view class that is available since C++17, see https://abseil.io/tips/1 .

cc @S-Dafarra this could be related to our discussion of yesterday.

Related old discussions and comments:

traversaro · 2018-03-10T11:41:37Z

Additional comment to notify that I modified my review.

barbalberto · 2018-03-12T09:44:26Z

@traversaro The rationale behind this is the same behind the image::setExternal, i.e. there is the need of using some yarp vector features on external memory without copying the data.
The need is to have a way to wrap a PCL pointCloud in yarp in a copy-less fashon.

What happens if in an "external" vector the resize method is called?

If a resize has to be called after the setExternal, problems will arise, exactly like it happens now for the yarp image.
This method is for advanced users who knows what they are doing. Some sanity check can be added, but cannot be 100% safe.

Only operation which do not change the memory allocation are safe to be used.
Using a different type like the vectorWrap will not solve this use case because at compile time we do not know if the user will choose to use an internal or external memory.

traversaro · 2018-03-12T12:02:38Z

If a resize has to be called after the setExternal, problems will arise, exactly like it happens now for the yarp image.

I was not aware of this, it sounds like a design flaw in yarp::sig::Image that should be fixed (or at least properly documented, neither Image::resize nor Image::setExternal mention this), rather than a pattern to propagate to other classes.

This method is for advanced users who knows what they are doing. Some sanity check can be added, but cannot be 100% safe.

The problem is that, while this peculiar behaviour has always been the case for yarp::sig::Image, for yarp::sig::Vector I personally always wrote code assuming that yarp::sig::Vector could be resized (and this is indeed suggested by the resize signature, that returns void), so I never taken care to check if the resize could fail (the only possible failure was due to a failure in memory allocation, and typical that is much more catastrophic) . I am afraid that most of the users of yarp::sig::Vector assumed the same.

Using a different type like the vectorWrap will not solve this use case because at compile time we do not know if the user will choose to use an internal or external memory.

Not sure about the specific case you are refereeing to, but any interface that takes in a yarp::sig::Vector without the need to resize it can take a mutable VectorView, as you can easily convert a yarp::sig::Vector to a valid VectorView.

claudiofantacci · 2018-03-12T12:36:43Z

I don't know the course of history of YARP development, but since there exist a bool owned in ManagedBytes I guess that, at some point, that particular variable has not been used to control whether a derived class, say yarp::sig::Image used in combination with setExternal, was allowed to manipulate memory or not.

I guess that if we want a clean implementation, we either improve yarp::sig::Vector implementation or we use another class that explicitly does not menage memory. The former solution may be more fruitable by users that are familiar with yarp::sig::Vector, but its implementation will be more complicated and documentation must be improved. The latter solution is probably overall a cleaner solution.

This method is for advanced users who knows what they are doing. Some sanity check can be added, but cannot be 100% safe.

Why is that?

barbalberto · 2018-03-12T13:07:49Z

I was not aware of this, it sounds like a design flaw in yarp::sig::Image that should be fixed (or at least properly documented, neither Image::resize nor Image::setExternal mention this), rather than a pattern to propagate to other classes.

I think it is a trade-off between efficiency and robustness. If user wants to be safe, data can be copied instead of calling a setExternal.
The fact you were not aware is a sign that it is not causing too much troubles 😝
I agree documentation shall be improved and better state what you can or can't to after a setExternal.

I don't know the course of history of YARP development, but since there exist a bool owned in ManagedBytes I guess that, at some point, that particular variable has not been used to control whether a derived class, say yarp::sig::Image used in combination with setExternal, was allowed to manipulate memory or not.

Images do not use ManagedBytes, they simply have a char *. Anyway, yes, image could have his own bool owned to perform some additional check. Neither I know why it is not present, maybe it was not added because images rarely are reshaped after the creation.

Some sanity check can be added, but cannot be 100% safe.
Why is that?

Because when someone else owns the memory, he/she can shrink or free that memory regardless of what we do, and there is no way for us to be notified. The next access will then cause a segfault.

Some check can be added on our side, for example to skip the resize when the memory is not owned, but as @traversaro said, users usually do not check if the resize has correctly been performed.

But the user knows if a setExternal has been called, so better inform users that it is not valid to call a resize after it.
I think the only real weapon we have is the documentation.

claudiofantacci · 2018-03-12T13:22:55Z

But the user knows if a setExternal has been called, so better inform users that it is not valid to call a resize after it.
I think the only real weapon we have is the documentation.

Improving documentation is always good! 😄
Anyway my two cents here is to also "block" some functions when setExternal is called.

Because when someone else owns the memory, he/she can shrink or free that memory regardless of what we do, and there is no way for us to be notified. The next access will then cause a segfault.

If we are clear about the behavior induced by a setExternal call, then it's the developer responsibility to be aware of this aspect.

Anyway, I'm open to either create a new dedicated class or to improve the class in conjunction with setExternal.

Nicogene · 2018-03-13T14:08:52Z

What about yAssert(owned) inside the functions that manage the memory ? e.g. push_back, pop_back, resize etc...
By default owned will be set to true and changed to false in the moment setExternal is called.

Nicogene · 2018-03-13T16:59:16Z

But the resizing of the vector that owns the memory is not controllable in my opinion.. so if we want this method and then efficiency, we have to accept some risks, as @barbalberto said it is a trade off...

barbalberto · 2018-03-14T08:18:37Z

A well done assert should evaporate when compiled in release mode, therefore if yarp is compiled in release, an application using the vector will not be affected by the assert.
My opinion is that whatever we use as a check, it should work also in release mode

Maybe we can have a f2f chat about which precaution measures to adopt.

claudiofantacci · 2018-03-14T08:23:03Z

Maybe we can have a f2f chat about which precaution measures to adopt.

I agree 😄 Can you please schedule one?

Nicogene · 2018-03-14T08:38:09Z

@barbalberto @traversaro @drdanz @claudiofantacci what about tomorrow in the late morning ?

traversaro · 2018-03-14T09:15:13Z

@Nicogene Ok for me, please send a meeting request on Outlook, thanks!

randaz81 · 2018-03-14T09:43:06Z

Only loosely related, but just yesterday I was working with std::vector<bool> and I realized that it does not implement method data() which is available in c++11 (http://www.cplusplus.com/reference/vector/vector/data) for generic std::vector<T>.
The reason is that std::vector<bool> has a specialized implementation for space optimization.(https://stackoverflow.com/questions/46115669/why-does-stdvectorbool-have-no-data).
So beware these kind of issues...

Nicogene · 2018-03-15T10:42:44Z

A comment to notify the partecipants that setExternal has been removed from the yarp::sig::Vector* classes, it will be implemented in the VectorMap classes.

…ction. Does not change the behaviour for standard types, but enables the possibility to implement specific read/write function for template types

@pattacini

cc @pattacini @claudiofantacci

drdanz · 2018-03-15T21:40:28Z

src/libYARP_OS/include/yarp/os/ManagedBytes.h

+     * @param extData, pointer to the external data.
+     * @param len, size in bytes of the external blob
+     */
+    void setExternal(const char* extData, size_t len);


2 comments here.
First of all, this should not be const char*, but just char, since the data is not owned, but can be modified. Second, I suggest to use const Bytes& ext instead, like in the other constructor, in order to make the interface more coherent

I see your point but I tried to be as much coherent as possible to yarp::sig::Image::setExternal:

yarp/src/libYARP_sig/include/yarp/sig/Image.h

Lines 247 to 252 in 29e9108

/**

* Use this to wrap an external image.

* Make sure to that pixel type and padding quantum are

* synchronized (you can set these in the FlexImage class).

*/

void setExternal(const void *data, int imgWidth, int imgHeight);

What is the best option ? 😅

lornat75 · 2018-03-15T22:35:14Z

interesting discussion on setExternal, why not adding a runtime check? I also like @traversaro idea to use dedicated classes for static check, however, it seems difficult to do it now.

traversaro · 2018-03-16T16:37:57Z

@Nicogene I know it is not entirely the fault of the newly introduced setExternal method, but can you please updatae the documentation of the allocate and allocatedOnNeed methods when called on ManagedBytes vector that have the owned attribute set to true ?

Nicogene · 2018-03-16T16:44:21Z

Ok, I will do a cleanup/documentation extra commit!

traversaro · 2018-04-09T11:45:16Z

@Nicogene I do not know if you are still interested in implementing the VectorMap class.

However, I discovered that a std::span class with similar semantics is currently being standardized:

As we did in the past for similar classes (such as RecursiveMutex) the best option may be to just introduce a yarp::os::Span class that follows the interfaced of the future std::span, and eventually migrate to the standard one when it is available on all the platforms that we need to support.

Nicogene · 2018-04-09T14:44:59Z

For now it is in standby but I will take a look, thanks!

Nicogene · 2019-04-12T09:51:16Z

This PR has to be finished and rebased, and have to take account to the (possible) introduction of move semantics in ManagedBytes (see #1974).

The move semantics + the shared ownership of the memory are an exploding mix if not managed correctly. I experienced it on my skin with the yarp::sig::Image (#1979)

traversaro · 2019-04-12T10:05:22Z

@Nicogene as far as I understand the consensus on this was to drop the setExternal(see #1582 (comment)).

If the consensus changed or in any case the decision of adding setExternal to Vector has been take, it would be nice to comment on the rationale behind this choice and how the methods that assume that the memory is owned (such as resize/push_back/...) will be handled.

Nicogene · 2019-04-12T10:11:06Z

@traversaro if I do remember correctly, we accord to define a separate class called VectorMap to use shared memory, and keep the Vector as it is.
But probably, for the VectorMap class, we need to implement setExternal in ManagedBytes or use another class, std::span-like.

traversaro · 2019-04-12T10:16:10Z

But probably, for the VectorMap class, we need to implement setExternal in ManagedBytes or use another class, std::span-like.

As far as I understand, VectorMap will never need to allocate/deallocate the memory that it is pointing to, so I do not know if there is any advantage of using ManagedBytes in it. Probably using yarp::os::Bytes or manually storing pointer and size would be simpler?

By the way, I just realized: if we want to use VectorMap to receive a vector from the network, how do we handle the case in which the vector size is different from the expected? The read will fail?

Nicogene · 2019-04-12T11:38:19Z

so I do not know if there is any advantage of using ManagedBytes in it. Probably using yarp::os::Bytes or manually storing pointer and size would be simpler

You are right, Bytes should be enought. 👍

Then this PR triggered a nice discussion about memory management and ownership but I think that can be closed now, and open a different one that introduce VectorMap.

Nicogene · 2019-04-12T11:40:52Z

By the way, I just realized: if we want to use VectorMap to receive a vector from the network, how do we handle the case in which the vector size is different from the expected? The read will fail?

I would say yes, but I have not a strong opinion on that.

Nicogene added PR Type: Feat/Enh This PR adds some new feature or enhances some part of YARP Component: Library - YARP_os Component: Library - YARP_sig Target: YARP v3.0.0 labels Mar 9, 2018

Nicogene requested review from drdanz and barbalberto March 9, 2018 17:34

drdanz added the Status: In Progress label Mar 9, 2018

claudiofantacci self-requested a review March 9, 2018 18:13

drdanz suggested changes Mar 9, 2018

View reviewed changes

claudiofantacci suggested changes Mar 9, 2018

View reviewed changes

traversaro requested changes Mar 10, 2018

View reviewed changes

Nicogene force-pushed the addSetExternal branch from a99e254 to edac4ca Compare March 13, 2018 16:43

Nicogene force-pushed the addSetExternal branch from edac4ca to 924eba2 Compare March 15, 2018 10:37

Nicogene changed the title ~~Add setExternal in Vector and VectorOf~~ Add setExternal in ManagedBytes Mar 15, 2018

Nicogene added the Component: Tests label Mar 15, 2018

Nicogene mentioned this pull request Mar 15, 2018

PointCloud in YARP #1597

Merged

Alberto Cardellino and others added 6 commits March 15, 2018 17:30

VectorOf.h: add implementation of read / write calling vectorBase fun…

9fd7c2b

…ction. Does not change the behaviour for standard types, but enables the possibility to implement specific read/write function for template types

libYARP_OS: add setExternal in ManagedBytes.

fd13e59

cc @pattacini @claudiofantacci

tests: enable VectorOfTest

02f481f

Update release notes

e20c77f

VectorOfTest: cleanup, removes unused classes

1607336

VectorOfTest: fix checkSendReceiveInt test.

b9ee051

Nicogene force-pushed the addSetExternal branch from 924eba2 to b9ee051 Compare March 15, 2018 16:34

drdanz suggested changes Mar 15, 2018

View reviewed changes

traversaro mentioned this pull request Mar 30, 2018

Implement externally owned vector and matrices robotology/idyntree#430

Closed

Nicogene changed the title ~~Add setExternal in ManagedBytes~~ [WIP] Add setExternal in ManagedBytes Apr 24, 2018

aerydna added Target: Future and removed Target: YARP v3.0.0 labels May 24, 2018

traversaro mentioned this pull request Jul 20, 2018

Fixed size buffers manager #1807

Merged

Nicogene closed this Apr 12, 2019

Nicogene deleted the addSetExternal branch April 12, 2019 11:38

Nicogene added Resolution: Withdrawn and removed Status: In Progress labels Apr 12, 2019

		* Read vector from a connection.
		* return true iff a vector was read correctly

	/**
	* Use this to wrap an external image.
	* Make sure to that pixel type and padding quantum are
	* synchronized (you can set these in the FlexImage class).
	*/
	void setExternal(const void *data, int imgWidth, int imgHeight);

[WIP] Add setExternal in ManagedBytes #1582

[WIP] Add setExternal in ManagedBytes #1582

Conversation

Nicogene commented Mar 9, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

claudiofantacci commented Mar 9, 2018

Choose a reason for hiding this comment

traversaro left a comment • edited Loading

Choose a reason for hiding this comment

traversaro commented Mar 10, 2018

barbalberto commented Mar 12, 2018

traversaro commented Mar 12, 2018

claudiofantacci commented Mar 12, 2018

barbalberto commented Mar 12, 2018

claudiofantacci commented Mar 12, 2018

Nicogene commented Mar 13, 2018 • edited Loading

Nicogene commented Mar 13, 2018

barbalberto commented Mar 14, 2018

claudiofantacci commented Mar 14, 2018

Nicogene commented Mar 14, 2018

traversaro commented Mar 14, 2018

randaz81 commented Mar 14, 2018 • edited Loading

Nicogene commented Mar 15, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lornat75 commented Mar 15, 2018

traversaro commented Mar 16, 2018

Nicogene commented Mar 16, 2018

traversaro commented Apr 9, 2018

Nicogene commented Apr 9, 2018

Nicogene commented Apr 12, 2019

traversaro commented Apr 12, 2019

Nicogene commented Apr 12, 2019

traversaro commented Apr 12, 2019

Nicogene commented Apr 12, 2019

Nicogene commented Apr 12, 2019

Nicogene commented Mar 9, 2018 •

edited

Loading

traversaro left a comment •

edited

Loading

Nicogene commented Mar 13, 2018 •

edited

Loading

randaz81 commented Mar 14, 2018 •

edited

Loading