Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
On Wed, Mar 19, 2014 at 7:43 PM, MinRK benjami...@gmail.com wrote: 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. Points taken. It's arguable that such code belongs in libzmq at all. Clearly people do like it, and we know that moving common functionality into libzmq can be profitable. For CZMQ I rewrote the proxy code though. There is a tendency to wrap CZMQ instead of libzmq, and that may resolve this old discussion of what belongs where. I think few people are using the raw libzmq API any longer, so it's a bit moot. WRT versioning, our rules don't specify it (any more, unless I've missed something). We used to refer to semantic versioning, but that opened the door to catastrophic release shifts (2.x vs 3.x vs 4.x). -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
If this fix is backported without incrementing the minor version number, then it presents the challenge of how to identify whether the functionality is present on a particular system when wrapping it in a language binding, because version 4.0.4 could refer both to the prior version without the functionality, or to the later version with the functionality. Cosmo On Thu, Mar 20, 2014 at 12:41 AM, Pieter Hintjens p...@imatix.com wrote: On Wed, Mar 19, 2014 at 7:43 PM, MinRK benjami...@gmail.com wrote: 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. Points taken. It's arguable that such code belongs in libzmq at all. Clearly people do like it, and we know that moving common functionality into libzmq can be profitable. For CZMQ I rewrote the proxy code though. There is a tendency to wrap CZMQ instead of libzmq, and that may resolve this old discussion of what belongs where. I think few people are using the raw libzmq API any longer, so it's a bit moot. WRT versioning, our rules don't specify it (any more, unless I've missed something). We used to refer to semantic versioning, but that opened the door to catastrophic release shifts (2.x vs 3.x vs 4.x). -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
This patch would go into the next stable, which is 4.0.5. On Mar 21, 2014 3:06 AM, Cosmo Harrigan cosmo.harri...@singularityu.org wrote: If this fix is backported without incrementing the minor version number, then it presents the challenge of how to identify whether the functionality is present on a particular system when wrapping it in a language binding, because version 4.0.4 could refer both to the prior version without the functionality, or to the later version with the functionality. Cosmo On Thu, Mar 20, 2014 at 12:41 AM, Pieter Hintjens p...@imatix.com wrote: On Wed, Mar 19, 2014 at 7:43 PM, MinRK benjami...@gmail.com wrote: 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. Points taken. It's arguable that such code belongs in libzmq at all. Clearly people do like it, and we know that moving common functionality into libzmq can be profitable. For CZMQ I rewrote the proxy code though. There is a tendency to wrap CZMQ instead of libzmq, and that may resolve this old discussion of what belongs where. I think few people are using the raw libzmq API any longer, so it's a bit moot. WRT versioning, our rules don't specify it (any more, unless I've missed something). We used to refer to semantic versioning, but that opened the door to catastrophic release shifts (2.x vs 3.x vs 4.x). -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
Ah, that makes sense. There will be no issue then. Thanks, Cosmo On Thu, Mar 20, 2014 at 9:02 PM, Pieter Hintjens piet...@gmail.com wrote: This patch would go into the next stable, which is 4.0.5. On Mar 21, 2014 3:06 AM, Cosmo Harrigan cosmo.harri...@singularityu.org wrote: If this fix is backported without incrementing the minor version number, then it presents the challenge of how to identify whether the functionality is present on a particular system when wrapping it in a language binding, because version 4.0.4 could refer both to the prior version without the functionality, or to the later version with the functionality. Cosmo On Thu, Mar 20, 2014 at 12:41 AM, Pieter Hintjens p...@imatix.com wrote: On Wed, Mar 19, 2014 at 7:43 PM, MinRK benjami...@gmail.com wrote: 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. Points taken. It's arguable that such code belongs in libzmq at all. Clearly people do like it, and we know that moving common functionality into libzmq can be profitable. For CZMQ I rewrote the proxy code though. There is a tendency to wrap CZMQ instead of libzmq, and that may resolve this old discussion of what belongs where. I think few people are using the raw libzmq API any longer, so it's a bit moot. WRT versioning, our rules don't specify it (any more, unless I've missed something). We used to refer to semantic versioning, but that opened the door to catastrophic release shifts (2.x vs 3.x vs 4.x). -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
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 benjami...@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 p...@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.harri...@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 p...@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.harri...@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 p...@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.harri...@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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
On Wed, Mar 19, 2014 at 12:56 AM, Pieter Hintjens p...@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 benjami...@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 p...@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.harri...@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 p...@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.harri...@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 p...@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.harri...@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@lists.zeromq.org
Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
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 p...@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.harri...@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 p...@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.harri...@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 p...@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.harri...@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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
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.harri...@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 p...@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.harri...@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 p...@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.harri...@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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
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 p...@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.harri...@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 p...@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.harri...@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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
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.harri...@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 p...@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.harri...@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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
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.harri...@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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
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 p...@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.harri...@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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Pattern for clean shutdown of a proxy loop
Long term, I would think it best to extend one of the C++ wrappers, probably zmqpp, with czmq functionality. (This could even be a wrapper to the wrapper.) Short term, it isn't that hard to replicate the design by creating your own inproc socket in zmqpp or whatever that is used together with a poller. On Tue, Mar 11, 2014 at 3:58 PM, Cosmo Harrigan cosmo.harri...@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 p...@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.harri...@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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
