Hi Justin, This is an area of some debate. We've had patches to libzmq that made sockets thread safe, and removed those patches again. Sharing sockets between threads for the most part is bad for design and performance. However there are languages where this just essential, for the reasons you describe.
My advice would be to solve this in the language binding. Simply create socket access routines (send/recv) that do the necessary locking. -Pieter On Sat, Nov 30, 2013 at 7:30 AM, Justin Karneges <jus...@affinix.com> wrote: > Hi folks, > > What's the latest on the thread-safety of sockets? I know that normal > 0MQ practice suggests not using a socket from multiple threads, but I > wonder if this is nonetheless possible, for example by wrapping a mutex > around access. > > The reason I ask is I'm exploring the possibility of using 0MQ in a > hybrid event-driven & threaded C++ environment (imagine something like > Goroutines or .NET tasks). A socket would never be used by two threads > simultaneously, but the thread on which a socket is utilized could > change depending on how the eventing system dispatches work. For > example, a task executing in one thread could go to sleep while it waits > for a message and then wake up in a different thread when a message > becomes available. > > I just want to confirm that this is a valid usage of 0MQ, before I do > something that might not be possible or might get broken in a future > release. > > Justin > _______________________________________________ > 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
