[zeromq-dev] level-triggered FD

[Justin Karneges]

Also beware that inproc sockets are broken with ZMQ_FD. https://github.com/zeromq/libzmq/issues/1434

If you decide to work on level-triggered FDs, you might ensure that it
works for all socket types.

On Tue, Jan 26, 2016, at 09:29 AM, Doron Somech wrote:
> I will give it some time in the ZeroMQ hackathon :-)
>
> On Tue, Jan 26, 2016 at 5:51 PM, MinRK <benjaminrk at gmail.com> wrote:
>>
>>
>> On Fri, Jan 22, 2016 at 5:30 PM, Doron Somech
>> <somdoron at gmail.com> wrote:
>>> the FD must be read-only, it might be possible in some OS but I
>>> won't be portable.
>>>
>>> Regarding the Command FD, it must be used, otherwise the Recv/Send
>>> FD won't work.
>>>
>>> So in your case you need to be add the event-loop both the command
>>> FD (which is the regular FD) and Recv/Send FD.
>>>
>>> When command FD is signaled you must call zmq_process_comands, which
>>> currently doesn't exist. When recv/send FD is signaled you can call
>>> recv/send. zmq_process_command it what causing the other FDs to get
>>> signaled.
>>>
>>> The bottom line, this is kind of syntactic sugar, it will be the
>>> equivalent of calling has_in or has_out immediately after FD is
>>> signaled and only then call recv/send.
>>
>>
>> Gotcha, thanks for the explanation. I think this will still be a huge
>> improvement.
>>
>>
>> -MinRK
>>
>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jan 22, 2016 at 5:54 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>>
>>>>
>>>> On Fri, Jan 22, 2016 at 4:19 PM, Doron Somech <somdoron at gmail.com>
>>>> wrote:
>>>>> The FD today is signalled when ever a command should be processes.
>>>>> What we can do is split it to 3 different FD:


>>>>> * Command FD : The one being used right now, this still must be
>>>>>   used, when ever signalled call process commands (which we should
>>>>>   expose in API).
>>>>>
* Recv FD: use as level triggered to receive.
>>>>>
* Send FD: use as level triggered to send.

>>>>> Only issue with this solution, you should include in your event
>>>>> loop minimum two FD, one for processing commands and one for send/
>>>>> recv.


>>>>
>>>> I think two FDs would be fine; certainly better than what we have
>>>> now. It would eliminate the significant problem of one signal for
>>>> separate events. Perhaps this is a naïve question: Is it not
>>>> possible to have an FD signal writable when the socket becomes
>>>> writable and readable when the socket becomes readable? If they
>>>> both have to be read-only FDs, that seems fine, as long as the
>>>> signaling for send and recv are separated somehow. I'm not sure
>>>> what users would do with the Command FD.
>>>>
>>>>
>>>> -MinRK
>>>>
>>>>
>>>>> For thread safe sockets this is a little simpler as we can make
>>>>> one FD for all sockets for processing commands.


>>>>> On Jan 22, 2016 2:52 PM, "Pieter Hintjens" <ph at imatix.com> wrote:
>>>>>> Yes, the edge triggered FD in libzmq has been a constant
>>>>>> source of
>>>>>>
annoyance. Maybe someone on this list knows how to fix it.
>>>>>>
>>>>>>
On Fri, Jan 22, 2016 at 1:40 PM, MinRK <benjaminrk at gmail.com> wrote:
>>>>>>
> Hi all,
>>>>>>
>
>>>>>>
> I've implemented yet another eventloop integration in pyzmq
> (asyncio, this
>>>>>>
> time), and this is only nontrivial because of the edge-triggered
> read-only
>>>>>>
> zmq.FD. Integrating into existing eventloops would be much easier
> if we had
>>>>>>
> a more traditional level-triggered FD to work with.
>>>>>>
>
>>>>>>
> Is there a technical reason why we can't add a zmq.LEVEL_FD that would
>>>>>>
> behave in a more conventional manner:
>>>>>>
>
>>>>>>
> - level-triggered
>>>>>>
> - signal write when socket is writable
>>>>>>
> - signal read when socket is readable
>>>>>>
>
>>>>>>
> I would work on this myself, but unfortunately I don't think I
> have the
>>>>>>
> relevant expertise.
>>>>>>
>
>>>>>>
> -MinRK
>>>>>>
>
>>>>>>
> _______________________________________________
>>>>>>
> zeromq-dev mailing list
>>>>>>
> zeromq-dev at lists.zeromq.org
>>>>>>
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>>
>
>>>>>>
_______________________________________________
>>>>>>
zeromq-dev mailing list
>>>>>> zeromq-dev at lists.zeromq.org
>>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>
>>>>> _______________________________________________
>>>>>
zeromq-dev mailing list
>>>>> zeromq-dev at lists.zeromq.org
>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
zeromq-dev mailing list
>>>> zeromq-dev at lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>>
zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>
>>
>> _______________________________________________
>>
zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
> _________________________________________________
> zeromq-dev mailing list zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160126/95a84811/attachment.htm>