[zeromq-dev] zproxy (hopefully) improvements

Thu Dec 5 20:31:37 CET 2013

One of the stated goals of czmq itself is backwards compatibility to libzmq 2.2 - and libzmq 2.2 has zmq_device, which was the first (afaik) implementation of the zmq_proxy idea.

So I definitely want zproxy in czmq to work from 2.2 to head (which has zmq_proxy_steerable).

I think I'm going to do a refactor on my local czmq branch that goes with "option 1" on my list - using defines to add or remove appropriate calls based on the version of libzmq built against.   Then we'll have examples of both of my implementation ideas to discuss.

I agree in spirit with Pieter on asserts - I'm very much in the "fails fast" camp - but in this case, removing calls that do nothing based on version is definitely still a firm of "fail fast", and while I'm torn between my first and third options, I think both are better than returning errors.

So give me a little time to not be hyptothetical and hack up the other option so I can understand the full impact on code complexity vs raising the asserts and I'll get back to everyone.

Once again, thanks to everyone participating in this discussion!

Brian

From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Lindley French
Sent: Thursday, December 05, 2013 2:12 PM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] zproxy (hopefully) improvements

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

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

--
AJ Lewis
Software Engineer
Quantum Corporation

Work:    651 688-4346<tel:651%20688-4346>
email:   aj.lewis at quantum.com<mailto: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<mailto: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/20131205/27258a3c/attachment.htm>