[zeromq-dev] zproxy (hopefully) improvements

[AJ Lewis]

Who's only using static linkage?  I'm using shared objects and DLLs with
zeromq and czmq exclusively.

AJ

On Thu, Dec 05, 2013 at 12:12:09PM -0500, Lindley French wrote:
> This is mostly an academic question so long as libzmq is statically linked.
> If it were ever dynamically linked, it would be much more important to get
> this right.
> 
> The distinction is similar to what the C++ standard library classifies as a
> "logic error" vs a "runtime error". A logic error means, "Hey, you,
> programmer. Yes, you. You did something bad. It's your fault I crashed." I
> have no particular problem using asserts to protect against this (although
> if you are literally calling "assert(condition)", be aware these calls
> disappear when NDEBUG is defined), or in general crashing immediately at
> this point. Bugs are easier to pin down that way.
> 
> A "runtime error" means "The code the programmer wrote *could* have worked
> in some cases, but it didn't work this time. Would you like to try
> something else?" An example might be trying to contact a server which is
> currently down. Asserts, exits, etc are incredibly inappropriate in these
> sorts of cases. Use an error code (or an exception in C++), so the program
> has a chance to recover from the problem.
> 
> In the scenario you describe, it sounds like calling those methods is a
> logic error. My first impression is that option #1 is the best, on the
> theory that errors should be caught as soon as possible, and option 1
> allows you to catch this error at compile time or link time, instead of
> waiting for runtime. On the other hand, linker errors can be notoriously
> difficult to diagnose, so an informative runtime error can sometimes be
> preferable.
> 
> 
> On Thu, Dec 5, 2013 at 11:32 AM, Brian Knox <briank at talksum.com> wrote:
> 
> > To go into more detail:
> >
> > Calling zproxy_pause, zproxy_resume, and zproxy_terminate on libzmq 2.2 ->
> > 4.0 does not do anything, as zmq_proxy_steerable was added after 4.0.
> >
> > I mulled over three approaches to address this:
> >
> > 1) Have an #if ZMQ_VERSION macro that simply removed those methods if czmq
> > is built against a libzmq does does not have zmq_proxy_steerable
> > 2) Throw an assert if those methods are called when czmq is built against
> > a libzmq that does not have zmq_proxy_steerable
> > 3) Do nothing, and return a -1 when those methods are called when czmq is
> > built against a libzmq that does not have zmq_proxy_steerable
> >
> > My gut was leaning  towards going with option #2, but I talked myself into
> > going with option #3 rationalizing that it was "more backwards compatible".
> >
> > However, since the calls won't actually do anything except return an error
> > code - perhaps exploding via an assert is a more assertive communication
> > that the API user has tried to do something that can not work.  Thinking
> > about it, I can't think of a scenario where I would want my code to call
> > these functions when czmq is built against a libzmq that can't support them.
> >
> > Lindley and Pieter - thank you both for your feedback!
> >
> > Brian
> >
> > -----Original Message-----
> > From: zeromq-dev-bounces at lists.zeromq.org [mailto:
> > zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Pieter Hintjens
> > Sent: Thursday, December 05, 2013 11:12 AM
> > To: ZeroMQ development list
> > Subject: Re: [zeromq-dev] zproxy (hopefully) improvements
> >
> > On Thu, Dec 5, 2013 at 2:52 PM,  <lindleyf at gmail.com> wrote:
> >
> > > I'm of the opinion that asserts should only be used to signal an
> > internal problem with the library. Any external interface should instead
> > use error codes if the input is detectably bad. So the question becomes, if
> > you build against a lower version of ZMQ, is that an error or does it just
> > reduce your capabilities? Can you require a minimum version, and check this
> > at init time?
> >
> > CZMQ already uses very extensive asserts to catch bad arguments.
> > Building against a lower version of libzmq is fine. Trying to use
> > non-existent features is bogus, IMO.
> >
> > -Pieter
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >

> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev


-- 
AJ Lewis
Software Engineer
Quantum Corporation

Work:    651 688-4346
email:   aj.lewis at quantum.com

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.