Imagine a simple workflow:
A -> B -> C
A produces some histogram, B alters it (f.e. adds a fill colour to the histogram) and sends to C without copy.
You cannot share histograms (THn) in shared memory (because of the the virtual table), so what you describe there will always have to go through a copy. This is a general problem and not a DPL limitation. Notice also that because of Address Layout Randomization of modern linux distributions, there is no hope to get it to work.
The only solution would be to write you own PoD histogram class, but also in that case you need to assume that the objects are immutable, so any modification (e.g. changing the color) would need to go through an extra object, not alter the original one.
Thank you, this is the answer I needed.
Isn’t immutability of POD actually forced by InputRecord now? In general, I make assumption that any data I subscribe inside Dispatcher arrives unmodified by someone else. I hope this is a good assumption.
Yes, we try as much as possible to protect that, but being naive shared memory a const_cast can screw that up. What would be nicer is if FairMQ used CoW to exchange messages, so that any process trying to write on the inputs would effectively force a page fault and write on a distinct copy.