[zeromq-dev] ZMQ_FAIL_UNROUTABLE functionality change / BC

[Ian Barber]

On Sun, Jun 17, 2012 at 11:06 AM, Paul Colomiets <paul at colomiets.name>wrote:

> Hi Ian,
>
> It's probably OK for doing the change at this stage. But is the
> feature designed carefully? The problem is that many asynchronous
> loops are probably do start polling on EAGAIN, and retry when poll
> succeeds. Which basically means they will go into tight loop until
> peer appears again (which is probably never).
>
>
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.

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