[zeromq-dev] thread affinity

[Min RK]

> On Nov 30, 2013, at 9:30, Justin Karneges <justin at affinix.com> wrote:
> 
> Great, it sounds like the answer to my question is that it is possible 
> to use the same socket from different threads provided I do my own 
> locking. That's perfectly workable. I mainly wanted to be sure there 
> wasn't something in libzmq explicitly preventing this kind of usage. For 
> example, I believe it is impossible to share a socket across threads 
> with pyzmq, but this must be a limitation imposed in the binding rather 
> than in libzmq.

Pyzmq imposes no restrictions on how you use sockets, so it is perfectly possible to share them across threads using locks (or not, and just risk segfault).


> 
>> On 11/30/2013 01:05 AM, Pieter Hintjens wrote:
>> 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 <justin at 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 at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev