On Mon, Dec 2, 2013 at 3:15 PM, Greg Ward <g...@gerg.ca> wrote: > On 30 November 2013, Pieter Hintjens said: > > 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. > > But doesn't that mean holding a lock during a potentially blocking > operation? E.g. if I send() to a REQ socket that has hit its > high-water mark, send() will block. If I'm holding a mutex during that > operation, than other threads can block on that mutex for a long time. > That sort of nasty cascading lock situation can go very bad very > quickly in my experience. >
You are holding a lock on a resource while it's not safe for another thread to use it. If you have significant contention on one of these locks, it means you are trying to have significant concurrent access on a single socket, and the lock will effectively serialize those threads. This is really why sharing sockets across threads is ill advised. You can use locks to move a socket from one thread to another, but it is only useful if that transaction is sufficiently rare, such as when blocking zmq calls are a minority of your app's run time. -MinRK > > Greg > _______________________________________________ > 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
