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
