[zeromq-dev] PUB/SUB pattern, rate control and backpressure

[Chuck Remes]

On Dec 12, 2011, at 1:19 PM, Michel Pelletier wrote:

> On Sat, Dec 10, 2011 at 3:08 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
>> 2. The application thread will push massages to the pipe and if the pipe
>> is full it will *block*.
> 
>> Thoughts? Does anyone see any problem with this approach?
>> 
> 
> What would happen if the socket was constructed with a non-blocking
> option?  Would it set EAGAIN, or should a new error like ERATELIMIT be
> set?

If this library is intended to eventually make its way into the kernel, then we don't want to introduce new errno's. I think returning EAGAIN is sufficient. If the programmer *must* know that the send failure occurred due to a rate limiting issue, then perhaps there could be a new socket option to return that information, e.g. zmq_getsockopt(ZMQ_EAGAIN_DETAIL).

cr