[zeromq-dev] level-triggered FD

KIU Shueng Chuan nixchuan at gmail.com
Wed Jan 27 00:04:32 CET 2016


I don't see how this can be the case since zmq_poll() internally uses
ZMQ_FD to implement level triggering for zmq sockets.

https://github.com/zeromq/zeromq4-1/blob/master/src/zmq.cpp
On 27 Jan 2016 02:59, "Justin Karneges" <justin at affinix.com> wrote:

> 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
>
>
>
> _______________________________________________
> 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/20160127/4eca04d4/attachment.htm>


More information about the zeromq-dev mailing list