On Sun, Jun 17, 2012 at 7:29 PM, Paul Colomiets <[email protected]> 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
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
