[zeromq-dev] making inproc into transproc

Goswin von Brederlow goswin-v-b at web.de
Sat Feb 1 13:13:22 CET 2014

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.


More information about the zeromq-dev mailing list