Am 01.02.2014 um 13:13 schrieb Goswin von Brederlow <[email protected]>:

> 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
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to