[zeromq-dev] level-triggered FD
MinRK
benjaminrk at gmail.com
Fri Jan 22 16:54:23 CET 2016
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160122/fafa6431/attachment.htm>
More information about the zeromq-dev
mailing list