[zeromq-dev] Static zmq context in Windows DLL
Hello, I've encountered this issue: https://github.com/zeromq/czmq/issues/1788 Basically when exiting the application, I get this error: *Assertion failed: Successful WSASTARTUP not yet performed.* I am using ZeroMQ on windows inside a DLL. I have a global static zeromq context, because I want it persistent across multiple instances of my objects, and there is no central place I could pass it from otherwise. The proposed solution is to call zsys_shutdown() before exiting the application, but I don't know how and where: - This function is not available through the API that I am using (zmq.h/zmq.hpp) - Not sure where would I call it, as I don't know when the application exits. In my library there is no main object that could control the lifetime of the zmq layer Any idea how to approach this? Kinds regards, Attila ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Which socket to choose?
Thanks Santosh, I can make this work, but honestly it's over-complicated for a simple client-server pattern. I feel like ZeroMQ is really lacking in this aspect. I wish there would be some support for the draft sockets; even to make them work as they are. Regards, Attila On Tue, Aug 20, 2019 at 7:23 PM wrote: > Hi Attila, > > Router-dealer combination is great for your design. You can refer to > major-domo example in the guide which describes a great design for multi > client-server application. > > Thanks, > Santosh Bidaralli > > -Original Message- > From: zeromq-dev On Behalf Of Brett > Viren via zeromq-dev > Sent: Tuesday, August 20, 2019 7:37 AM > To: Attila Magyari > Cc: Brett Viren; ZeroMQ development list > Subject: Re: [zeromq-dev] Which socket to choose? > > > [EXTERNAL EMAIL] > > Hi again, Attila, > > Attila Magyari writes: > > > So having two sockets, one for sending and one for receiving is the > > way to go? > > Disclaimer: I'm a zeromq amateur so take my advice as such. I don't know > if this two-socket approach is best but it's certainly one way to do it. > (For a design that takes multi-socket communication to an extreme, check > out the description in ipython's documentation about how it communicates > between its parts.) > > > By message order restrictions I meant the send/recv pattern to be > > unrestricted, no mandatory order of send/recv. The server could send > > an arbitrary number of messages to the client. > > Okay. I guess this ordering is referring to the "Send/receive pattern" > eg as listed in the zmq_socket(3) man page. REQ/REP is a lock-step > pattern: send/recv/send/recv/send/recv... > > ROUTER and DEALER both have "unrestricted" send/receive pattern. A ROUTER > on the "server" side and a DEALER on each "client" may work for you. > There's a bit of detail in that the ROUTER application has to manage a > "routing id" as the first part of every message. But, given that you can > have two-way, 1-to-N, async message passing without a send/receive pattern > restriction. > > > One-to-many as in one server socket to handle multiple client > > connections, just like the CLIENT/SERVER sockets. > > ROUTER-DEALER fits this too. Understanding your needs better now I would > suggest checking if this pattern suits you before trying the two-socket > approach. > > Cheers, > -Brett. > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Which socket to choose?
Thanks Brett, So having two sockets, one for sending and one for receiving is the way to go? By message order restrictions I meant the send/recv pattern to be unrestricted, no mandatory order of send/recv. The server could send an arbitrary number of messages to the client. One-to-many as in one server socket to handle multiple client connections, just like the CLIENT/SERVER sockets. Regards, Attila On Mon, Aug 19, 2019 at 7:22 PM Brett Viren wrote: > Attila Magyari writes: > > > Reading the docs all the other sockets seem to have extra restrictions or > > complications, which would not meet my needs: > > - bidirectional > > I assume you mean symmetrically bidirectional? > > If so, a pair of PUSH/PULL (or PUB/SUB) on each end would provide that. > > > - no message order restrictions > > I don't know what this means here. > > > - one-to-many client-server type of connections > > Also, unclear to me. > > Client-server implies reply-request which is not (symmetrically) > bidirectional. > > One DEALER may send the same request to many REP or ROUTER sockets. > > -Brett. > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Which socket to choose?
Hello, Currently I am using ZMQ_PAIR for interprocess communications over TCP. As the docs say, this should not work correctly as I use it, hence I am getting some undesired behavior from time to time. I would like to use a different socket, and the CLIENT/SERVER ones would be absolutely perfect. However after waiting for more than a year for them to become stable, and there's no progress whatsoever in this direction, I would like to try with something else. Reading the docs all the other sockets seem to have extra restrictions or complications, which would not meet my needs: - bidirectional - no message order restrictions - one-to-many client-server type of connections Is there any socket which would fulfill these requirements? Thank you, Attila ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Installing PyZMQ with draft sockets
Hello, Does anyone have experience building PyZMQ on Windows with draft sockets enabled? I tried the following the steps from here: pyzmq .readthedocs.io/en/latest/draft.html but I'm having errors I can't overcome: For building pyzmq, I tried using using the bundled libzmq, which has library mismatches, as I'm getting unresolved external symbols: unresolved external symbol __imp_zmq_msg_set_routing_id referenced in function __pyx_pf_3zmq_7backend_6cython_7message_5Frame_18set I also built libzmq separately, with draft sockets enabled, and use that to build pyzmq, but the folder structure is not the same, and again some library mismatch, unresolved symbols. Any ideas on how to proceed? Maybe even download already built wheels with drafts enabled from somewhere? Thanks, Attila ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Help using VSCode to build libzmq
To build libzmq you need to have a compiler. VSCode is not a compiler, so by default it doesn't build anything. You can install extensions for C++, which let you build code, but it requires some setting up. For building libzmq, you have several options, you can check them out in the builds directory. I can imagine that you could set up something in VSCode to execute one of these, but honestly I don't see the point of it. Assuming you are on Windows, if not ignore this last sentence, the easiest way for me to build libzmq was cmake + Visual Studio. cmake generates the solution files which are easily buildable in VS. On Fri, Nov 2, 2018 at 12:39 PM Osiris Pedroso wrote: > Hello, > > Coming back from a hiatus, I would like to work on the Github #3263 issue > (a Windows crash in libzmq). > I would like to use VSCode to build LIBZMQ, if possible. > Are there any VSCode users out there that could give me some pointers on > how to build LIBZMQ (or any of the ZMQ projects) using VSCode? > > Appreciate any pointers, > Osiris > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Installing PyZMQ with draft sockets
Hello, Does anyone have experience building PyZMQ on Windows with draft sockets enabled? I tried following the steps from here: pyzmq.readthedocs.io/en/latest/draft.html but I'm having errors I can't overcome: For building pyzmq, I tried using using the bundled libzmq, which has library mismatches, as I'm getting unresolved external symbols: unresolved external symbol __imp_zmq_msg_set_routing_id referenced in function __pyx_pf_3zmq_7backend_6cython_7message_5Frame_18set I also built libzmq separately, with draft sockets enabled, and use that to build pyzmq, but the folder structure is not the same, and again some library mismatch, unresolved symbols. Any ideas on how to proceed? Maybe even download already built wheels with drafts enabled from somewhere? Thanks, Attila ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZMQ_PAIR over TCP
@Esa, are these documents recent? I am currently using ZMQ_PAIR sockets and they do reconnect quite well. On Mon, Jun 18, 2018 at 1:05 PM Esa HekmatiZadeh wrote: > Hi James > According to zguide: > >> When you want to coordinate a set of nodes on a network, PAIR sockets >> won't work well any more. This is one of the few areas where the strategies >> for threads and nodes are different. Principally, nodes come and go whereas >> threads are usually static. PAIR sockets do not automatically reconnect if >> the remote node goes away and comes back. >> > As I understand from the above quote; Thanks to these characteristics PAIR > socket is more suitable for inproc environment where threads are statics > however you can use PAIR sockets over TCP as long as you aware and accept > the behavior of PAIR which does not reconnect. > > On Mon, Jun 18, 2018 at 3:31 PM, Attila Magyari wrote: > >> As I understood, the documents are outdated, and ZMQ_PAIR is supposed to >> work not only for inproc protocols. I am definitely not sure about this, >> and I as well use it for TCP, so would be interested in the answers. >> >> On Mon, Jun 18, 2018 at 12:40 PM James Harvey >> wrote: >> >>> Hi, >>> >>> >>> >>> I have been using ZMQ_PAIR recently for a one to one data feed over >>> TCP. I know the documentation doesn’t explicitly say this should work >>> (over TCP) but for the most part it does. Last week I came across a >>> situation where the bind end of the connection had reconnection issues if >>> no data is flowing during the bounce of the TCP connection. >>> >>> >>> >>> Before I go to the trouble of recreating/documenting the behavior (I >>> won’t call it a bug at this point) I want to know if there is support in >>> the zeromq community for ZMQ_PAIR to be supported over TCP? As far as I can >>> tell the documentation doesn’t explicitly say either way. >>> >>> >>> >>> I know there are other patterns (PUB/SUB, PUSH/PULL) that support TCP >>> but they are not as simple as the ZMQ_PAIR where you want a strict bi >>> directional one to one relationship. >>> >>> >>> >>> If it’s the case that ZMQ_PAIR is only to be used over inproc then maybe >>> the connect/bind should fail for anything other than inproc so people don’t >>> make mistakes and assume it’s going to work. >>> >>> >>> >>> Thanks >>> >>> >>> >>> James >>> ___ >>> zeromq-dev mailing list >>> zeromq-dev@lists.zeromq.org >>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> >> ___ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZMQ_PAIR over TCP
As I understood, the documents are outdated, and ZMQ_PAIR is supposed to work not only for inproc protocols. I am definitely not sure about this, and I as well use it for TCP, so would be interested in the answers. On Mon, Jun 18, 2018 at 12:40 PM James Harvey wrote: > Hi, > > > > I have been using ZMQ_PAIR recently for a one to one data feed over TCP. > I know the documentation doesn’t explicitly say this should work (over TCP) > but for the most part it does. Last week I came across a situation where > the bind end of the connection had reconnection issues if no data is > flowing during the bounce of the TCP connection. > > > > Before I go to the trouble of recreating/documenting the behavior (I won’t > call it a bug at this point) I want to know if there is support in the > zeromq community for ZMQ_PAIR to be supported over TCP? As far as I can > tell the documentation doesn’t explicitly say either way. > > > > I know there are other patterns (PUB/SUB, PUSH/PULL) that support TCP but > they are not as simple as the ZMQ_PAIR where you want a strict bi > directional one to one relationship. > > > > If it’s the case that ZMQ_PAIR is only to be used over inproc then maybe > the connect/bind should fail for anything other than inproc so people don’t > make mistakes and assume it’s going to work. > > > > Thanks > > > > James > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
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 <francesco.monto...@gmail.com> wrote: > 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 need > to monitor several sockets... > > HTH, > Francesco > > > 2018-05-25 9:09 GMT+02:00 Attila Magyari <att...@gmail.com>: > >> 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! >> >> ___ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
[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! ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Sharing socket safely between threads
Alright, thanks everyone, really useful info. I will rethink my design to eliminate the need for sharing the sockets between threads :). On Sun, May 13, 2018 at 1:03 AM Justin Karneges <jus...@karneges.com> wrote: > The real issue here is thread affinity. Mere thread-unsafety can always be > worked-around by the application developer, by ensuring that no two threads > ever access the same resource at the same time. It is my understanding that > libzmq sockets are not thread safe, but they also don't have thread > affinity, so you can access a single socket from different threads if you > handle safety on your own. > > Personally, I agree with the libzmq authors in that trying to do I/O on > the same socket from multiple threads is an anti-pattern. However, I > consider certain kinds of sharing to be legitimate, for example creating a > socket in one thread and then handing it off to a second thread, and only > that second thread does I/O. I think that fits within the spirit of libzmq, > since only one thread is actually doing I/O on the socket. If you find > yourself doing I/O on a socket from multiple threads, protecting the access > with a mutex, then you're in anti-pattern territory. That said, it should > work just fine, and libzmq authors' opinions won't stop you. :) > > FWIW, you might run into thread affinity in other libraries. For example, > last I checked, PyZMQ has thread-affinity of sockets. If you create a > socket in one thread and hand it off to another, I/O from the other thread > will fail. But it is my understanding that libzmq itself does not have such > limitation. > > On Sat, May 12, 2018, at 2:08 PM, Bill Torpey wrote: > > 1. FWIW, my personal experience has been that it is safe to share a > ZMQ_PUB socket between threads if protected with a mutex. Basically the > sequence is lock/send/unlock. > > The alternative is to have an internal zmq_proxy with inproc on one side > and something like TCP on the other side, which is an extra send/receive > hop. I have not found that to be necessary, and I have done a *lot* of > testing (which has found several other edge cases). > > FWIW the docs specifically bless this approach (http://zeromq.org/area:faq > ): > > For those situations where a dedicated socket per thread is infeasible, a > socket may be shared *if and only if* each thread executes a full memory > barrier before accessing the socket. Most languages support a Mutex or > Spinlock which will execute the full memory barrier on your behalf. > > and here (http://zguide.zeromq.org/page:all#Multithreading-with-ZeroMQ): > > Technically it's possible to migrate a socket from one thread to another > but it demands skill. > > > I have not tried doing that with ZMQ_SUB sockets — there is really no > point, as a sigle thread sitting in a zmq_poll call on multiple sockets is > probably the cleanest design anyway. > > > 2. I can definitely testify that trying to share a ZMQ_SUB socket > *without* mutexes is guaranteed to crash, and that trying to share a > ZMQ_SUB socket *with* mutexes is almost impossible to do without > deadlocking. > > > 3. Another situation is to have a single “main” thread setup all the > sockets at startup and then hand them off to other threads (and never touch > them again). Strictly speaking you may only need a memory barrier, but > using a mutex in this case ensures that you don’t try to use the socket > concurrently from more than one thread. > > > 4. Last but not least, if you’re planning on using inproc sockets for > inter-thread communication, you may find this helpful: > https://github.com/WallStProg/zmqtests/tree/master/threads > > > On May 8, 2018, at 3:58 PM, Thomas Rodgers <rodg...@twrodgers.com> wrote: > > No, not really. I have designed my zmq based systems to either - > * orchestrate connections over the inproc transport > * performed the delicate dance of explicitly passing a fresh socket to a > fresh thread the way that czmq actors > <http://czmq.zeromq.org/manual:zactor> work, > as implemented in azmq > <https://github.com/zeromq/azmq/blob/master/azmq/detail/actor_service.hpp> > > On Mon, May 7, 2018 at 11:58 AM, Attila Magyari <att...@gmail.com> wrote: > > This sounds promising. My concern is if there are some background threads > internally in the ZMQ library, which would use the socket out of sync with > mine, or anything else that I'm not thinking about. I can ensure that the > socket won't be used from multiple threads. > > Do you have any experience with this, or only theory? > > Thank you, > Attila > > > On Mon, May 7, 2018 at 5:49 PM Thomas Rodgers <rodg...@twrodgers.com> > wrote: > > The zmq docs say you need to
Re: [zeromq-dev] Sharing socket safely between threads
This sounds promising. My concern is if there are some background threads internally in the ZMQ library, which would use the socket out of sync with mine, or anything else that I'm not thinking about. I can ensure that the socket won't be used from multiple threads. Do you have any experience with this, or only theory? Thank you, Attila On Mon, May 7, 2018 at 5:49 PM Thomas Rodgers <rodg...@twrodgers.com> wrote: > The zmq docs say you need to ensure a ‘full fence’ a mutex is one way of > achieving that. > > If you are using C++ (-std=c++11 or later) and you can guarantee there is > no racy usage from another thread, you can issue a memory fence using - > > std::atomic_thread_fence > > On Mon, May 7, 2018 at 8:42 AM Attila Magyari <att...@gmail.com> wrote: > >> Hello, >> >> I know that zmq sockets are not thread safe. However I can't think of a >> good design (explained below) without using the socket in several threads. >> What I want to do is connect the socket in a thread, and then use it in a >> different one until the end, and never in parallel between several threads. >> I will guard the access with a mutex as well. Do you think this will be >> safe? >> >> Just in case someone might have a better idea for my design, here is what >> I'm trying to do: >> I have an application which starts another process, passes a port to the >> newly created process, so it can connect back to the main application >> through a ZMQ_PAIR socket. Both processes are local to the machine. The >> main application will request from the second one, but the second one can >> initiate messages without an explicit request as well. Do you have a nicer >> design to achieve something like this? >> >> Thank you in advance! >> > ___ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Sharing socket safely between threads
Hello, I know that zmq sockets are not thread safe. However I can't think of a good design (explained below) without using the socket in several threads. What I want to do is connect the socket in a thread, and then use it in a different one until the end, and never in parallel between several threads. I will guard the access with a mutex as well. Do you think this will be safe? Just in case someone might have a better idea for my design, here is what I'm trying to do: I have an application which starts another process, passes a port to the newly created process, so it can connect back to the main application through a ZMQ_PAIR socket. Both processes are local to the machine. The main application will request from the second one, but the second one can initiate messages without an explicit request as well. Do you have a nicer design to achieve something like this? Thank you in advance! ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
