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 <[email protected]> wrote: >> >> >> On Fri, Jan 22, 2016 at 5:30 PM, Doron Somech >> <[email protected]> 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 <[email protected]> wrote: >>>> >>>> >>>> On Fri, Jan 22, 2016 at 4:19 PM, Doron Somech <[email protected]> >>>> 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" <[email protected]> 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 <[email protected]> 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 >>>>>> > [email protected] >>>>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>>>> > >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
