Support min alignment in ChannelResource #282
Conversation
| /// This is the allocator that interfaces to FairMQ memory management. All | ||
| /// allocations are | ||
| /// delegated to FairMQ so standard (e.g. STL) containers can construct their | ||
| /// stuff in | ||
| /// memory regions appropriate for the data channel configuration. | ||
| class ChannelResource : public FairMQMemoryResource | ||
| template<std::size_t MinAlignment> | ||
| class AlignedChannelResource : public FairMQMemoryResource |
There was a problem hiding this comment.
is the name change necessary? Since the default behavior does not change (or does it?), signatures do not change (as far as I can see) it seems to be the same animal, just a better behaved one :)
There was a problem hiding this comment.
If I don't change the name, it would not let me do the name alias: using ChannelResource = ChannelResource<0>; - do you know how to make it work?
There was a problem hiding this comment.
template <int alignment = 0>
struct ChannelResource {
};no?
It would be per factory, but one could create more than one per factory as before, see usage in the unit test in this PR. The |
|
ok, so it looks essentially like the workaround we have in O2 (@ktf ?). This would give us no further advantage aside from not having this specific allocator in our code base. How about the thing we briefly discussed with @rbx (AliceO2Group/AliceO2#3674 (comment)) for a bit more transparency? |
Yes, it is nothing more.
Sure, I am fine with making the default alignment configurable on that API layer, too. Just the same question for my understanding, whats the improvement over just using the pmr interface above to create messages? Or, in other words, what makes the pmr solution - even if only a specialized pmr class in O2 repo - just a workaorund? Are we just talking about API design or is there any technical difference you want to see? |
|
@dennisklein I'd say it is about API design mostly, technically we have all the pieces, but just would like to avoid confusion. TransportFactory::GetMemoryResource() (and the implicit conversion operator) are just too seductive not to use :) Just saying it could be potentially dangerous if the default API (above) and the thing we actually need (explicitly constructed allocator as it is now) return the same thing different only in subtle ways like (over-)alignment. |
dennisklein
force-pushed
the
dev
branch
6 times, most recently
from
39b5f74
to
a1e5962
Compare
Related to #265