[zeromq-dev] zeromq, abort(), and high reliability environments
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
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
> > 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
> > 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.
> zeromq-dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev