[zeromq-dev] zeromq, abort(), and high reliability environments

Pieter Hintjens ph at imatix.com
Thu Aug 14 14:04:37 CEST 2014

On Thu, Aug 14, 2014 at 12:22 PM, Michi Henning <michi at triodia.com> wrote:

> On that note: Why is zmq using "void *" instead of declaring abstract
> types?

Horrid C API design by individuals who felt C++ was the superior
language and that POSIX socket API compatibility was more important
than usability. We should have fixed this in ZMQ v2 and failed. It's
been on my list of WTFs for a long time.

In CZMQ we're moving to a zsock_t type for this and when that API is
stable it could be worth backporting it to libzmq, so that it's
available in all languages. Or, people can wrap CZMQ as is happening.

> I've been puzzled by that one too. A pointer to an opaque struct would
> eliminate a lot of errors at compile time.


> That said, I can live with the aborts and the weak type checking, mainly
> because it's not too difficult for me to structure my code such that these
> errors become impossible. I'm more concerned about the policy angle.

In fact libzmq does not assert on bad arguments, that's CZMQ's style.
libzmq only asserts on irrecoverable internal states, where continuing
would be dangerous and where the code MUST be fixed for sane work to

It's CZMQ that does the militant "how can you expect me to respect
your existence when you pass me garbage" asserts on bad arguments.
CZMQ also has very strong types and substantial opinions about C
language style. Personally I find this all makes C lovely to work
with, and fast failure is part of that.

As regards failures in a distributed system, the goal should be,
perhaps, fast failure of individual pieces followed by rapid recovery
and decent logging. However you really do not want buggy code running
on production data... that's bad no matter how you slice it.


More information about the zeromq-dev mailing list