[zeromq-dev] qzmq
I've written a Qt-based wrapper to zmq here: https://github.com/jkarneges/qzmq There are some similar projects already (zeromqt, nzmqt), but I wanted to do things a little differently. Maybe people will find it useful. Today I discovered there is another project already called qzmq, that provides bindings to the Q language. Well, don't confuse it with that. :) Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] OpenSUSE Build Service for ZeroMQ
On Wed, Jun 27, 2012 at 3:43 PM, Feng Shuo steve.shuo.f...@gmail.com wrote: Just an update. I create two upstream builds in the OBS by it's git source service. Whenever there is a commit, OBS will pull the updates and do a on all platforms... Nice. On the http://www.zeromq.org/community page there is a section for builds and distros, and you might add an OpenSUSE page here (http://zeromq.distro:opensuse). -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] HWM behaviour blocking
Hi Justin, On Thu, Jun 28, 2012 at 8:50 AM, Justin Karneges jus...@affinix.com wrote: On Thursday, May 10, 2012 01:53:48 PM Pieter Hintjens wrote: On Thu, May 10, 2012 at 3:44 PM, Paul Colomiets p...@colomiets.name wrote: Can you be more specific, why setting HWM to 1 is a bad thing? Do you mean, that it smells bad to set HWM to 1 for reliability? Or do you think that setting it will have other consequences? (low performance?) it's bad because you're trying to force a synchronous model on an asynchronous system, and doing it at the wrong level. If you really want synchronization you MUST get some upstream data from the receiver. Just throttling the sender cannot work reliably. I'm about to set HWM to 1 and I recalled a thread about this so I've looked it up. Totally agree about what's been said so far. The reason I want to do this is because I need a way for an event-driven application to determine if data has been written to the underlying kernel. This is useful in case the application wants to close the socket immediately after writing data. In a traditional blocking application, this is easy: just call zmq_close() and it'll unblock when done. However, in an event-driven application, the only way I can think of imitating this functionality is by setting HWM to 1 and waiting until ZMQ_EVENTS indicates writability, then calling zmq_close(). Why you need zmq_close in the asynchronous application in the first place? Is your application very connection hungry? We never close zeromq sockets even on fairly low traffic connections, and it works nice. -- Paul ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] HWM behaviour blocking
On Thursday, June 28, 2012 03:50:57 AM Paul Colomiets wrote: Hi Justin, On Thu, Jun 28, 2012 at 8:50 AM, Justin Karneges jus...@affinix.com wrote: On Thursday, May 10, 2012 01:53:48 PM Pieter Hintjens wrote: On Thu, May 10, 2012 at 3:44 PM, Paul Colomiets p...@colomiets.name wrote: Can you be more specific, why setting HWM to 1 is a bad thing? Do you mean, that it smells bad to set HWM to 1 for reliability? Or do you think that setting it will have other consequences? (low performance?) it's bad because you're trying to force a synchronous model on an asynchronous system, and doing it at the wrong level. If you really want synchronization you MUST get some upstream data from the receiver. Just throttling the sender cannot work reliably. I'm about to set HWM to 1 and I recalled a thread about this so I've looked it up. Totally agree about what's been said so far. The reason I want to do this is because I need a way for an event-driven application to determine if data has been written to the underlying kernel. This is useful in case the application wants to close the socket immediately after writing data. In a traditional blocking application, this is easy: just call zmq_close() and it'll unblock when done. However, in an event-driven application, the only way I can think of imitating this functionality is by setting HWM to 1 and waiting until ZMQ_EVENTS indicates writability, then calling zmq_close(). Why you need zmq_close in the asynchronous application in the first place? Is your application very connection hungry? We never close zeromq sockets even on fairly low traffic connections, and it works nice. It's really just for functional completeness of my event-driven wrapper. The only time I can see this coming up in practice is an application that pushes a message just before exiting. For now, I set ZMQ_LINGER to 0 when a socket object is destroyed, making the above application impossible to create. What I'm thinking of doing now is offering an alternate, blocking-based shutdown method. This would violate the spirit of my wrapper, but may work well enough for apps that finish with a single socket doing a write-and-exit. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
