[zeromq-dev] ZMQ_FAIL_UNROUTABLE functionality change / BC

[Ian Barber]

On Sun, Jun 17, 2012 at 7:29 PM, Paul Colomiets <paul at colomiets.name> wrote:

> I think that documenting "Never use this option if you don't know the
> internals of your reactor" might help. But it looks strange. But
> without it people may submit a bugs like "zeromq eats 100% cpu".
>

Definitely adding something to the documentation at the least is sensible
though. I guess what I was thinking with the two options, was that binding
authors that had reactors of this nature could silently replace
setsockopt(ZMQ_..., 1 with (ZMQ_..., 2 in this case, and handle the
EHOSTUNREACH. Alternatively, binding authors in the other case could handle
EHOSTUNREACH more like an EAGAIN or other interrupt type failure.


> The pull request description says:
> > '1' forces the socket to fail with an EAGAIN error code on
> > unroutable messages, enabling the library user to use
> > blocking sends, sends with timeout and other useful stuff
> > while waiting for the peer to appear, like with the other
> > socket types.
>
> Does this mean, that side-effect of this patch is that blocking send
> will block until peer is up again? (Or it just returns EAGAIN?)
>

Will just return EAGAIN.

Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120618/d66fe765/attachment.htm>