> Silently consuming infinite memory is nasty; the assertion is a> placeholder > for "please insert better strategy here". In this case,> harsh is what we > want. Figured so, and quite agree as well.
> Blocking seems the right strategy since it's consistent with other > reliable outgoing sockets. +1 it's what I would expect as well. What about zmq_setsockopt? Should there be a nonblocking version of ZMQ_SUBSCRIBE to emulate behavior of send (on XSUB)? Masking perhaps? zmq_setsockopt(sub_s, ZMQ_SUBSCRIBE | ZMQ_NOBLOCK, "foo", 3) Too ugly? :) On Mon, Dec 19, 2011 at 18:00, Pieter Hintjens <[email protected]> wrote: > On Mon, Dec 19, 2011 at 9:01 AM, Daniel Lundin <[email protected]> wrote: > >> send_subscription will assert if the socket has reached SNDHWM, where >> it before would eventually run out of memory if a corresponding PUB >> peer never showed up. >> >> In any case, an assertion is pretty harsh when reaching exceptional state. > > Silently consuming infinite memory is nasty; the assertion is a > placeholder for "please insert better strategy here". In this case, > harsh is what we want. > >> I don't have a good idea what behavior an XSUB *should* exhibit in >> that case, though, I think perhaps it'd make more sense to block (like >> PUSH)? > > Blocking seems the right strategy since it's consistent with other > reliable outgoing sockets. Returning an error just means every > application has to handle this (and most won't handle it properly). > Setting HWM to infinite is the worst strategy IMO. > > -Pieter > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
