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

Pieter Hintjens ph at imatix.com
Wed Mar 19 08:56:01 CET 2014


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).


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
>



More information about the zeromq-dev mailing list