[zeromq-dev] Assert in XSUB (send_subscription)

Daniel Lundin dln at eintr.org
Mon Dec 19 18:29:21 CET 2011


> 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 <ph at imatix.com> wrote:
> On Mon, Dec 19, 2011 at 9:01 AM, Daniel Lundin <dln at eintr.org> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



More information about the zeromq-dev mailing list