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. 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
