[zeromq-dev] PUB/SUB unreliabiliity

itlists at schrievkrom.de itlists at schrievkrom.de
Tue Jun 17 12:38:00 CEST 2014

I'm not sure, if I understand all these problems - but making assert
seems to throw some kind of signal - and I'm using 0MQ only by calling
the dynamic library (no C code) - and whenenver the call throws an
assert - my application crashes. I seem not to be able to handle these
kinds of exceptions - or my dev. environment does not allow to handle
such signals.

Though I handle all error (return) code in my wrappers and signal erros
within my application - my application crashes simply, when an assert
within the 0MQ code is thrown.

I noticed this behaviour when playing with 0MQ under XP and pgm where
some internal assert were fired under strange circumstances. I had to
gave up using pgm, because handling these errors was not possible.


Am 17.06.2014 11:42, schrieb Michi Henning:
> Hi Pieter,
> I'm not objecting to this as such. I agree that I need all the help I can get from tools :-)
> It's just that calling assert in a library because an invalid argument was passed is generally not the done thing, which is why I'm suggesting that being able to turn that behavior off would be nice. By all means, make asserting the default. But it would probably be nice to be able to turn this off.
> The real cause here is the type-unsafe API for setting the option. (Yes, I know, it's the C way of doing things…)
> Cheers,
> Michi.
> On 17 Jun 2014, at 17:23 , Pieter Hintjens <ph at imatix.com> wrote:
>> I think the actual evidence (I've seen two very expensive debug
>> stories caused by this same behavior in the last few weeks) shows that
>> returning an error in such a case is meaningless, and that a library
>> asserting when passed bad arguments is measurably more robust, not
>> less robust. I'm 100% sure of this. It's how CZMQ has worked since the
>> start, including in the socket option classes, and no-one has ever
>> flagged that as problematic. The only plausible use case is for tests,
>> which is circular.
>> However, changing existing behavior isn't allowed by our C4
>> development contract, so I was thinking of making this optional via a
>> build-time option in libzmq.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Marten Feldtmann

More information about the zeromq-dev mailing list