I\'m using ZeroMQ publish–subscribe sockets to connect two processes. The publishing process is a sensor, and has a much faster refresh rate than the subscription process. I
Okay, I found a solution, but I don't know if it's the best one — so I won't mark it as correct just yet.
zmq::message_t message;
int events = 0;
size_t events_size = sizeof(int);
// Priming read
subscriber.recv(&message);
// See if there are more messages to read
subscriber.getsockopt(ZMQ_EVENTS, static_cast(&events), &events_size);
while (events & ZMQ_POLLIN) {
// Receive the new (and perhaps most recent) message
subscriber.recv(&message);
// Poll again for additional messages
subscriber.getsockopt(ZMQ_EVENTS, static_cast(&events), &events_size);
}
// Now, message points to the most recent received data.
This strategy has the added advantage that the queue shouldn't fill up. The disadvantage is that my publisher could conceivably send faster than this loop in the subscriber could be run, and then it'll loop indefinitely.
That seems unlikely, but I'd like to make it impossible. I'm not quite sure how to accomplish this goal yet.