[zeromq-dev] level-triggered FD

[Doron Somech]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160126/5fc55da9/attachment.htm>