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