Receiver: return after timeout even if more data is pending

[eile]

No description provided.

[tribal-tec]

more like "with very fast sender(s)"

[tribal-tec]

nice formatting :)

[rdumusc]

@eile @tribal-tec this commit breaks the http server in Tide, which is based on QSocketNotifier. I don't understand what you were trying to achieve here. Doing a non-blocking receive() using timeout=0 is not allowed anymore? Please advise.

[eile]

Seems there is no test for this. :P

This PR fixed that if the publisher is faster than the subscriber, a subscriber.receive(timeout) would never return, even after the timeout expired.

This changes the behaviour of receive(0) which now will do one receive, not all (which is in line with the doc/spec).

Not sure why/how this breaks the QSocketNotifier.

[rdumusc]

OK, part of the problem is that the timeout is now used for two purposes:

• a poll timeout (waiting x milliseconds until SOME data arrives)
• a processing timeout (abort after processing TOO MUCH data)

I think the reason it breaks in Tide is because the zmq socket notifies only once data first arrives (edge triggered), not as long as there is data to read (level triggered). So now it only processes one message, exceeds the limit of 0 millisecond and stops instead of reading all messages.

[tribal-tec]

Wouldn't while(receive(0)); solve it then in Tide to process all pending?

[rdumusc]

seeing that receive() returns false when no messages were processed probably yes, I will test that next week