[zeromq-dev] Java API is not notifed of C++ assert failures.

Holger Hoffstätte holger at wizards.de
Mon Apr 20 12:08:35 CEST 2009


sorry for the late reply. I somehow thought I had already answered but
apparently did not.

Martin Sustrik wrote:
> This is pretty contentious issue. However, let's have a look at
> possibilities here:

No. :-)
There may or may not be reasons why asserts are raised, but that really
does not matter. zmq (when viewed as a library) is not responsible for the
lifetime of the process and should not suddenly assume it is. Other C
libraries don't just call "exit()" when they encounter an error either.

By trying to predict the exact reason for the assert - bug, incorrect
usage or whatever - you're only getting yourself deeper into trouble,
because there will always be a "surprise" reason that you didn't foresee.

Like I said, I understand the motivation for terminate-fast scenarios -
when zmq "is" the app or in safety-critical environments with n-version
agreement where single-party disagreement implies possible corruption and
requires immediate system shutdown. I think we can rule that out for now.

Again, stopping work/shutting down zmq is not the issue: assuming control
over the process is.

> In short, if you are having problem with a specific assert, let's fix
> the problem. Don't try to introduce complex generic mechanisms to handle
> the unhandleable.

I am not trying to "handle the unhandleable", I'm trying to isolate
failure behaviour so that I can shut down the subsystem in a controlled
way. Or rather let it do that itself and then tell me about it, so that I
can shut down the rest of the containing process cleanly or at least limp
along on the remaining legs for a few more minutes.

The only other alternative would be to start any zmq messaging as an
external process and talk to it via some other IPC mechanism as
trampoline, but that would make things even more fragile (managing ext.
process lifetime etc.) and also slower.

Hope that explains my reasoning. It's just a suggestion and concern that
came up during a review.


More information about the zeromq-dev mailing list