Hello Paul! On Wed, Apr 25, 2012 at 8:29 PM, Paul Colomiets <p...@colomiets.name> wrote: > Hi Gerhard, > > On Wed, Apr 25, 2012 at 6:08 PM, Gerhard Lipp <gel...@googlemail.com> wrote: >> i figured out to boil down an example, which shows this bug. >> it consists of three files: >> 1) x.lua doing the XREP XREQ stuff, must be started once >> 2) rep.lua implementing a simple echo replier, must be started once >> 3) req.lua making the request to rep.lua through x.lua. must be >> started TWICE to produce the error. THIS PROCESS LOCKS. uncommenting >> the ev.WRITE is a bad workaround to this issue. > > As far as I can see, it not a workaround. It's just the way ZMQ_FD works. > Uze zmq_poll if you don't feel comfortable for that. The only way you can > change > that is returning getopt(zmq.EVENTS) instead of hardcoding ev.READ + ev.WRITE >
According to the manual, the fd returned by zmq_getsockopt(ZMQ_FD) "signals any pending events on the socket in an edge-triggered fashion by making the file descriptor become ready for reading". If ev.WRITE is required to get all ZMQ_POLLIN and/or ZMQ_POLLOUT events, the doc should be clearer. Anyhow, as the source looks like, the ZMQ_FD is the fd associated with the socket's "mailbox", which is used for all kinds communication (state transitions?) inside of ZMQ. A "selecting/polling" user process should not wake up unnecessarily to avoid context switches, which are really expensive on our (embedded) device. Thus i'd like to minimize the wakeups by just specifying ev.READ. > -- > Paul > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
