Open Squadrick opened 4 years ago
I discovered your lib because my thought was, if I cannot manage memory across process (without writing a custom memory allocator) what can I do to go faster than memcopy.
Andrei gives a good hint on how to write allocators in std::allocator Is to Allocation what std::vector Is to Vexation, his talk also fixed something that was nebulous in my mind: multiple strategies for multiple sizes.
So currently, I'm trying to find how large a memory block has to be, to zero copy makes sense.
And, how iceoryx does it?
"iceoryx" is a pre-allocated memory space.
Here's one way to achieve this:
ptr
is allocated in the shared memory (usingAllocator
) and given to the user. We also assign an Element in the shared queue toptr
. We hold a writer lock on this element untilptr
is published. We may need to update the baseElement
to add an extra field:is_zero_copied
, so that the consumer can react accordingly.On the consumer side, we'll return a subclass of
Memblock
:ZeroCopyMemblock
which will not have ano_delete()
and will be deallocated at the end of the callback. We'll need to check the logic for locks as well.Code path for copied-communication:
New code path for zero-copy communication:
The above has been shown for pub-sub, but they can be extended to RPC too.
Here's a problem, we can't free each message pointer independently. A message pointer can only be free after all preceding message allocations are released, which is due to the logic in which
Allocator
works. It is a strictly FIFO-based allocation strategy. For performance, we may want to consider moving to a more complex general-purpose allocator.NOTE: Writing a general-purpose allocator to work on a single chunk of shared memory is very error-prone.