On Fri, Apr 18, 2014 at 01:23:59AM +0200, Michael Haberler wrote:
>
> Am 18.04.2014 um 00:33 schrieb Goswin von Brederlow <[email protected]>:
>
> > On Thu, Apr 17, 2014 at 10:54:59PM +0200, Michael Haberler wrote:
> >> Goswin,
> >>
> >> Am 17.04.2014 um 11:24 schrieb Goswin von Brederlow <[email protected]>:
> >>
> >>> On Wed, Apr 16, 2014 at 08:07:27PM +0200, Michael Haberler wrote:
> >>>> we're using zeroMQ in machinekit (formerly LinuxCNC)
> >>>>
> >>>> to retain the end-to-end principle, we need to be able to send multipart
> >>>> messages to and from RT threads
> >>>>
> >>>> that isnt possible with libzmq code since it's C++ and uses dynamic
> >>>> memory allocation
> >>>>
> >>>> the code which we'll be using is based on a lock-free ringbuffer in
> >>>> shared memory (ring_*), and a multipart framing layer on top of that
> >>>> (bring_*): http://psha.org.ru/cgit/psha/ring/?h=wip-buffer
> >>>>
> >>>> a proxy thread at the RT boundary translates from zmq to ringbuffer
> >>>> framing and back
> >>>>
> >>>> just in case somebody has a similar requirement
> >>>>
> >>>> - Michael
> >>>
> >>> doesn't zero-copy fix that?
> >>
> >> I dont understand what are you are suggesting, could you elaborate?
> >>
> >> - Michael
> >
> > You have your data in some buffer somewhere in memory. Then when you
> > can call zmq_msg_init_data() to make a message out of it without
> > copying the data:
>
> I think I should have mentioned the environment restrictions:
>
> The application is a cooperative ensemble of normal userland threads, and RT
> threads.
>
> All these threads share is a shm segment; nothing else. RT threads may live
> in the kernel, as a hypervisor thread like in Xenomai, or as a 'posix thread
> on steroids' with RT-PREEMPT. Or even on a core running an entirely different
> OS, or a bare metal code blob. The application works with either, which is
> why this framing was needed.
>
> The fact that you have some data outside such a shared memory segment has no
> bearing; it's not accessible.
>
> That said, the methods in the repo I pointed to support zero-copy writing at
> the frame level _within_ the shm segment.
>
> - Michael
>
> >
> > The zmq_msg_init_data() function shall initialise the message object
> > referenced by msg to represent the content referenced by the buffer
> > located at address data, size bytes long. No copy of data shall be
> > performed and ØMQ shall take ownership of the supplied buffer.
> >
> > If provided, the deallocation function ffn shall be called once the
> > data buffer is no longer required by ØMQ, with the data and hint
> > arguments supplied to zmq_msg_init_data().
> >
> > The deallocation function allows you to reuse buffers that zmq has
> > finished with so you don't need to dynamically allocate them. And the
> > data isn't copied so the zmq_msg functions run in constant time no
> > matter how large the buffer.
> >
> > MfG
> > Goswin
The point would be to use buffers in the shared memory segment from
the start so you can pass them from the normal threads to the RT
threads / kernel / barebone blob without the need of a proxy thread
that copies them.
MfG
Goswin
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev