Expanding on your first point: the file descriptor only triggers read notifications, and the notification means to query ZMQ_EVENTS. For example, when a zmq socket becomes writable, the ZMQ_FD file descriptor becomes readable, and you react to that by checking ZMQ_EVENTS and discover the zmq socket can be written to. Also you may be interested in https://github.com/jkarneges/qzmq On Sat, Apr 30, 2016, at 12:32 PM, Kalle Huttunen wrote: > The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why > can't I use standard I/O multiplexing functions such as select() or > poll() on ZeroMQ sockets?" question: > > > Note that there's a way to retrieve a file descriptor from ZeroMQ > > socket (ZMQ_FD socket option) that you can poll on from version 2.1 > > onwards, however, there are some serious caveats when using it. > > Check the documentation carefully before using this feature. > > I've prototyped integrating ZeroMQ socket receiving to Qt's and custom > select() based event loops, and on the first glance everything seems > to work. > > From the documentation I have identified two "caveats" that I handle > in my code: > > 1. The ability to read from the returned file descriptor does not > necessarily indicate that messages are available to be read from > the socket > > This I have solved by checking ZMQ_EVENTS before reading from > the socket. > > 2. Events are signaled in edge-triggered fashion > > This one I have solved by always receiving all the messages from the > socket when the file descriptor signals. > > Are there some caveats that I'm missing? > > -- > Kalle Huttunen > _________________________________________________ > 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
