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