[zeromq-dev] making inproc into transproc

Michael Haberler mail17 at mah.priv.at
Sat Feb 1 18:10:14 CET 2014

Am 01.02.2014 um 13:13 schrieb Goswin von Brederlow <goswin-v-b at web.de>:

> On Wed, Jan 29, 2014 at 10:09:20PM +0100, Michael Haberler wrote:
>> I understand the inproc sockets are dead-fast but inproc-only because the eventfd notification is used, which is compatible with  poll(2)
>> eventfd normally is used between threads or processes with common ancestors
>> however, it is possible to pass eventfd file descriptors between arbitrary processes using a somewhat arcane Unix socket/sendmsg/SCM_RIGHTS mechanism, which lifts the 'common ancestor' restriction;  I had to solve this working on a problem unrelated to zeroMQ (lock-free queues in shared memory, no common ancestor processes on either side). But it might be used in zeroMQ by placing ypipes into shared memory and and pass the eventfd's between processes. In my scenario I might also need to signal an eventfd from kernel space; there's an API for that.
>> Here is a working solution to the 'passing eventfd's between unrelated processes' problem : https://github.com/mhaberler/libancillary 
>> - Michael
>> ok, the subject was a joke;)
> There is one more difference. The message content needs to be
> allocated in shared memory too. And I think that changes the semantic
> of zmq_msg_init_data():
>    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.
> Would just require data to be allocated in shared memory? That would
> make code work with one kind of transport (all but transproc) but fail
> with another (transproc), which I believe is not the aim in zqm.

yeah, that occurred to me only after hitting send - the purpose I use that for has a ringbuffer of variable-sized records, not of references to messages or frames for that matter, so frame allocation in shm isnt needed

we have such a dynamic-objects-in-shared-memory thing in LinuxCNC, the baseaddress/offset notation for pointers is a real pain to work with

- Michael

> MfG
> 	Goswin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list