[zeromq-dev] Is shared ownership possible while sending with zero-copy?

[jricher]

I was working for Coroware on a similar project about 2.5 years ago. Even on lousy hardware, I was hitting link limits long before memory and allocations became an issue. 
While your mileage may vary, I suspect that zeromq will do well by you. 
Jacques Richer Jricher at jricher.com(602)350-2463

-------- Original message --------From: Stephan Opfer <opfer at vs.uni-kassel.de> Date: 9/1/17  12:22 AM  (GMT-07:00) To: zeromq-dev at lists.zeromq.org Subject: Re: [zeromq-dev] Is shared ownership possible while sending with
  zero-copy? 
Hi Patrik,

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.

Greetings,
   Stephan

> 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
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20170831/1adcf6fa/attachment.html>

-- 
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
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20170901/6c8f95fe/attachment.htm>