zmq::socket_poller_t::wait() had an important set of common lines
between POLL and SELECT variant.
Solution: refactor zmq::socket_poller_t::wait() and add the
following methods:
zmq::socket_poller_t::zero_trail_events()
zmq::socket_poller_t::check_events()
zmq::socket_poller_t::adjust_timeout()
Signed-off-by: Marc Sune <mardevel@gmail.com>
Solution: zmq_poller_wait_all signals all events
allows signaling multiple events with one call to zmq_poller_wait_all
rather than emitting only one event.
this prepares for zmq_poll being based on zmq_poller,
which requires events for all sockets rather than just one.
Solution: Provide poll() for Windows as well. This is a build option that
defaults to off as the resulting binary will only run on Windows Vista or
newer.
This is not tested with alternative Winsock service providers like VMCI,
but the documentation for WSAPoll does not mention limitations.
On my local machine, throughput improves by ~10 % (20 simultaneous
remote_thr workes to one local_thr, 10 byte messages), while latency
improves by ~30 % (measured with remote/local_lat).
