[zeromq-dev] What are the “serious caveats” with ZMQ_FD?
justin at affinix.com
Sat Apr 30 22:16:30 CEST 2016
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 at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev