[zeromq-dev] ZMQ_FAIL_UNROUTABLE functionality change / BC

[Paul Colomiets]

Hi Ian,

On Sun, Jun 17, 2012 at 8:07 PM, Ian Barber <ian.barber at gmail.com> wrote:
> Reasonable thought - it is only triggered by setting the sockopt, so
> presumably someone doing that will think through the implications (and be
> more likely to have the peer actually reappear if they've specifically asked
> for the message not to be silently dropped), though I think you are right
> that it might not play too nicely with some existing reactors, which could
> lead to user confusion.  Hard to say really - I don't have a strong opinion
> one way or the other. From Andrey's pull req it looks like he was
> specifically doing this because bindings tend to handle EAGAINs differently
> that other types of errors, so there is that side to think on. I guess
> having a third option that would return EHOSTUNREACH as opposed to EAGAIN
> would probably help those with reactors, so at least they would have the
> option of throwing that instead of being unable to distinguish between that
> an other EAGAIN cases.
>

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".

I don't think two similar options is a good solution either.

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?)

-- 
Paul