[zeromq-dev] thread affinity
Justin Karneges
justin at affinix.com
Sat Nov 30 18:30:53 CET 2013
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.
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
>
More information about the zeromq-dev
mailing list