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
