Re: [zeromq-dev] cppzmq revival and RFC on design goals and supported platforms

Hi Simon, thanks for reading my feedback and taking my thoughts into account! yes, if the decision to use doctest is done I can help migrate tests and will happily do this. we could just add the header, migrate one test after an other over a while, and than remove google test. than this will not

Re: [zeromq-dev] cppzmq - how to use ::monitor_t properly?

Thanks Francesco, I also used a separate thread for the monitoring, but as you said, if I create more sockets, I will be spawning new running threads which I can't join anymore. Doesn't sound like a good design :). On Fri, May 25, 2018 at 10:53 AM Francesco wrote:

Re: [zeromq-dev] cppzmq - how to use ::monitor_t properly?

Hi Attila, I use the zmq::monitor_t::monitor() call from the context of a secondary thread. In practice every time I want to monitor a socket (mostly for debugging) I create a new thread dedicated to its monitoring. This is an easy solution although probably is not the best one, specially if you

Re: [zeromq-dev] cppzmq revival and RFC on design goals and supported platforms

Hi Harald, * test framework: Personally I have no particular preference for googletest, and at first sight I think we could go with doctest as well. I agree that not needing a build step is a plus, in particular for a project like cppzmq, which is a header-only library itself. However,

[zeromq-dev] cppzmq - how to use ::monitor_t properly?

Hello, How do you use the cppzmq's zmq::monitor_t::monitor() call correctly? It is an infinitely blocking method, and I don't know how to exit from it gracefully. Is the use of socket monitoring discouraged? Are there better alternatives to get connection status of the socket? Thank you!