[zeromq-dev] Pattern for clean shutdown of a proxy loop

MinRK benjaminrk at gmail.com
Wed Mar 19 18:43:09 CET 2014


On Wed, Mar 19, 2014 at 12:56 AM, Pieter Hintjens <ph at imatix.com> wrote:

> Hmm... this would be more confusing than helpful IMO. 4.1.x should
> normally go through the usual 'release candidate' -> 'stable' process.
> This would suggest we can randomly backport new functionality so long
> as we update the version number. That isn't our process at all...


> If adding zmq_proxy_steerable can't be justified as fixing a bug, then
> we can't backport it.


> My view is that the old zmq_proxy is pretty unusable, and not much
> used. The fact that the code sat unmodified for years kind of proves
> it. I'm going to merge that pull request.


> We may need to modify our rules to allow backports of changes that
> seem exceptionally useful, or where the cost to e.g. bindings of not
> backporting seems too high (as here).
>

Amending the rules is fine, I just wanted to point out that you can't
backport new features without updating the minor version number within the
current definitions of libzmq minor and patch versions.

As an author and user of the pyzmq bindings, there is no cost to me in
failing to backport the steerable function. I have used zmq_proxy daily
(since it was called zmq_device), with no issue.  I don't actually have any
plan to expose the steerable version in pyzmq, because it doesn't offer any
real benefit in that context.

I don't think the steerable version of the function belongs in libzmq at
all, so backporting it seems a bit silly to me.

-MinRK


>
>
> On Tue, Mar 18, 2014 at 8:21 PM, MinRK <benjaminrk at gmail.com> wrote:
> > I think backporting the function is okay, but that would mean that
> zeromq4-x
> > should become 4.1.x, and libzmq should be bumped to 4.2.
> >
> >
> > On Mon, Mar 17, 2014 at 1:04 AM, Pieter Hintjens <ph at imatix.com> wrote:
> >>
> >> We don't usually backport new functionality to existing stable
> >> releases, because it's been troublesome in the past (i.e. breaking
> >> things in bad ways).
> >>
> >> However, this is fairly safe and if you want to make a pull request to
> >> zeromq4-x with the new zmq_proxy code, I'll merge it.
> >>
> >> I've made an issue https://github.com/zeromq/libzmq/issues/929 that
> >> you can refer to in the pull request.
> >>
> >> -Pieter
> >>
> >> On Mon, Mar 17, 2014 at 5:16 AM, Cosmo Harrigan
> >> <cosmo.harrigan at singularityu.org> wrote:
> >> > Thanks. Is it acceptable to backport zmq_proxy_steerable to libzmq
> >> > 4.0.4? Or
> >> > if not, when do you estimate the next stable release that would
> contain
> >> > it?
> >> >
> >> > Best,
> >> > Cosmo
> >> >
> >> >
> >> > On Tue, Mar 11, 2014 at 11:18 PM, Pieter Hintjens <ph at imatix.com>
> wrote:
> >> >>
> >> >> CZMQ has its own steerable proxy so that it can run on older versions
> >> >> of libzmq. Also, some optimizations, but that's secondary. Also,
> >> >> wrapping libzmq's method is extra work, it turns out.
> >> >>
> >> >> The zmq_steerable_proxy method is quite recent so hasn't been wrapped
> >> >> by other bindings yet.
> >> >>
> >> >> On Tue, Mar 11, 2014 at 11:58 PM, Cosmo Harrigan
> >> >> <cosmo.harrigan at singularityu.org> wrote:
> >> >> > Thanks for the reply. I took a look, and my understanding is that
> the
> >> >> > CZMQ
> >> >> > zproxy class waits for messages from both a backend and a pipe
> (which
> >> >> > is
> >> >> > a
> >> >> > PAIR socket to expose the API) and updates a local variable
> 'stopped'
> >> >> > which
> >> >> > ends the loop when the pipe receives the 'STOP' command.
> >> >> >
> >> >> > And it refers to that as a 'steerable proxy'.
> >> >> >
> >> >> > Then, I found that there is a class in libzmq called
> >> >> > zmq_proxy_steerable
> >> >> > (http://api.zeromq.org/4-1:zmq-proxy-steerable), which seems to
> offer
> >> >> > exactly what I was asking about.
> >> >> >
> >> >> > Why isn't CZMQ zproxy using zmq_proxy_steerable?
> >> >> >
> >> >> > For C++ programming, cppzmq doesn't wrap either of those classes.
> >> >> > Niether
> >> >> > does zmqpp.
> >> >> >
> >> >> > So, I'm wondering, what pattern do other people who are using
> ZeroMQ
> >> >> > in
> >> >> > C++
> >> >> > currently follow in this case to control their proxy loops? I
> suppose
> >> >> > one
> >> >> > solution is the one mentioned in the other thread, namely, wrapping
> >> >> > CZMQ
> >> >> > in
> >> >> > your C++ application. Any suggestions?
> >> >> >
> >> >> > Thanks,
> >> >> > Cosmo
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Tue, Mar 11, 2014 at 2:02 PM, Pieter Hintjens <ph at imatix.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> You can look at the CZMQ zproxy class to see one way to do this.
> >> >> >>
> >> >> >> On Tue, Mar 11, 2014 at 9:35 PM, Cosmo Harrigan
> >> >> >> <cosmo.harrigan at singularityu.org> wrote:
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > What is the best practice when you are creating a loop that
> >> >> >> > functions
> >> >> >> > like
> >> >> >> > the zmq_proxy device, to bind a PULL socket that is fed by a
> >> >> >> > backend
> >> >> >> > ventilator with a frontend PUB socket, in order to properly
> handle
> >> >> >> > a
> >> >> >> > clean
> >> >> >> > shutdown?
> >> >> >> >
> >> >> >> > Most of the examples on the zguide just show "while (1)" with a
> >> >> >> > loop
> >> >> >> > that
> >> >> >> > never terminates. What's the suggested way of signaling to the
> >> >> >> > loop
> >> >> >> > which is
> >> >> >> > running in its own thread that it is time to shut down?
> >> >> >> >
> >> >> >> > Thanks,
> >> >> >> > Cosmo
> >> >> >> >
> >> >> >> >
> >> >> >> > _______________________________________________
> >> >> >> > 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
> >> >> >
> >> >> _______________________________________________
> >> >> 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
> >
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140319/34c3ecb3/attachment.htm>


More information about the zeromq-dev mailing list