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

Thomas Rodgers rodgert at twrodgers.com
Thu Aug 14 14:22:13 CEST 2014


"Horrid C API design by individuals who felt C++ was the superior
language and that POSIX socket API compatibility was more important
than usability."

I'm not sure what C++ has to do with any of this.  It is certainly not
idiomatic 'modern' C++ to have raw void* or any raw resource owning
pointers for that matter.  This is more a product of POSIX style API...and
yeah, it's horrid.

On Thursday, August 14, 2014, Pieter Hintjens <ph at imatix.com> wrote:

> On Thu, Aug 14, 2014 at 12:22 PM, Michi Henning <michi at triodia.com
> <javascript:;>> 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.
>
> Indeed.
>
> > 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
> continue.
>
> 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.
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org <javascript:;>
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140814/963d0b3c/attachment.html>


More information about the zeromq-dev mailing list