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 <calid1...@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@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
