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

Thomas Rodgers rodgert at twrodgers.com
Tue Aug 12 02:38:10 CEST 2014

What exactly would an application do in the face of exhausting file
descriptors to recover?  I have encountered numerous cases with the JVM
where it's notion of finalization is decidedly too lazy to be of practical
use (memory mapped files/regions for instance).  I've also encountered
several instances where bugs in Hotspot have taken out a process.  Linux
has it's OOM killer feature which gives you no chance to recover.  Many
(perhaps most) of these situations are simply unrecoverable in any
practical sense except for terminating the process and letting some
supervisor restart the process.

In my mind, this is a completely distinct issue from whether or not the
library uses asserts vs EINVAL to report incorrect usage.  I tend to prefer
the latter in libraries I don't directly control, but I think it is
incumbent upon a given language binding to enforce correct usage and report
incorrect usage in the way that is most idiomatic to the language in
question.  In other-words, if the wrapper wants recoverable argument
validation, then it is the wrapper's responsibility to implement that;
assert() (and it's variants) are completely reasonable idioms for C and C++
pre-condition enforcement.

On Mon, Aug 11, 2014 at 7:15 PM, Dylan Cali <calid1984 at gmail.com> wrote:

> > Must not throw an assertion there. An exception in the highlevel
> > bindings (if the language has any) could be ok. That's a matter of
> > taste and language style.
> The problem with assertions/aborts from a user's perspective is that
> they cannot be caught like a 'real' Exception.  So, even with the jzmq
> bindings there are some situations (e.g. out of file descriptors)
> where libzmq will abort and take an entire Java application with it,
> giving it no chance for cleanup/recovery.
> My users say they don't feel comfortable using zeromq (or a client
> library that uses zeromq), in a high reliability application because
> of the possibility it will abort.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140811/f7e37b90/attachment.html>

More information about the zeromq-dev mailing list