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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 >>> [email protected] >>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
