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@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
