[zeromq-dev] Is shared ownership possible while sending with zero-copy?
opfer at vs.uni-kassel.de
Fri Sep 1 09:22:59 CEST 2017
it is very likely to be a premature optimization, but on the other hand we would like to replace the ROS Middleware with a combination of Cap'n Proto and ZeroMQ. So I actually don't know which kind of messages the following generations are trying to send. We, that is the Carpe Noctem Cassel RoboCup team (www.das-lab.net).
We usually play with 5 robots connected over a local access point. Therefore, we use UDP Multicast. An "extrem" example would be the transfer of 2D laser scan data: 1080 * 8 byte = 8640 byte, 30 times per second = 253.125 KByte / sec. Or for debugging purpose the transfere of a live camera stream with roughly 900x900 pixels. The required amount of memory per transfered image depends on the compression. For raw images it is 46.35 MBytes / sec.
> I'm just curious, how large are those sensor values, how many do you keep around, and to how many other robots do you intend to send them?
> Could it be premature optimization? Just asking because maybe it's not worth the extra effort to make it zero-copy. Just copy and pass ownership to ZMQ.
> Regards, Patrik
> On 31 Aug 2017, at 20:06, Thomas Rodgers <rodgert at twrodgers.com> wrote:
> Unfortunately that's not possible, libzmq exposes only a C API, and even though it is implemented in C++, it deliberately targets pre-C++11 compilers.
> Further to the 'mark and sweep' idea, or more generally, deferred reclamation. You could have the callback place the message to be freed on a (possibly lock free, Boost has a handy one) queue and signal a 'reaper' thread (waiting on a condition_variable). The reaper thread wakes up, reclaims all queued message buffers then returns to waiting.
>> On Thu, Aug 31, 2017 at 10:55 AM Stephan Opfer <opfer at vs.uni-kassel.de> wrote:
>> > Another, more complicated way, would be to implement a mark&sweep
>> > garbage collector of sorts: instead of freeing the buffer, the callback
>> > you register with zmq_msg_init_data would mark the buffer as done (in a
>> > thread safe way!). Then your application's garbage collector can sweep
>> > it.
>> It would be nice, if I could pass over a copy of (not reference or pointer to) a shared_ptr that owns the buffer, but with the call back and the "void * hint" this wasn't possible for me.
>> Distributed Systems Research Group
>> Stephan Opfer T. +49 561 804-6280 F. +49 561 804-6277
>> Univ. Kassel, FB 16, Wilhelmshöher Allee 73, D-34121 Kassel
>> WWW: http://www.uni-kassel.de/go/vs_stephan-opfer/
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
Distributed Systems Research Group
Stephan Opfer T. +49 561 804-6280 F. +49 561 804-6277
Univ. Kassel, FB 16, Wilhelmshöher Allee 73, D-34121 Kassel
More information about the zeromq-dev