[zeromq-dev] zproxy (hopefully) improvements

[AJ Lewis]

Absolutely - so if you build czmq against a newer version of zeromq, and
then drop that czmq build into an environment with an older version of
zeromq installed, what happens?  I think this fails spectacularly right now,
even before any of the changes discussed below.

On Thu, Dec 05, 2013 at 02:12:16PM -0500, Lindley French wrote:
> The thing about shared libraries is that they can turn logic errors into
> runtime errors. Therefore, you need to treat them as such, or else impose a
> minimum requirement on the library version and generate a runtime error at
> load time if you don't have one that's good enough.
> 
> 
> On Thu, Dec 5, 2013 at 2:07 PM, AJ Lewis <aj.lewis at quantum.com> wrote:
> 
> > 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.
> > _______________________________________________
> > 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