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" <[email protected]> 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 <[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 > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
