[zeromq-dev] Thread Safe sockets

[Martin Lucina]

On Mon, 6 Feb 2012 18:57:35 -0500
Joshua Foster <jhawk28 at gmail.com> wrote:

> I would like to put forth the motion that the sockets should not be thread safe. The multipart messages do not facilitate the ability for thread safety without some major complexity. This would involve the complexity of changing the API that breaks backwards compatibility or adding locks which would slow the API down.
> 
> My personal experience is that when people were trying to use a socket over multiple threads, it was wrong anyways. The asserts in libzmq catch the problem very quickly during development so we never see it in production which I think is better than having "demons" in the system and not understanding why.

+1

> The second is to use an inproc socket per thread and then create a device that transfers this data to the external socket. This has the least amount of problems with concurrency. If the community really wanted to create a "thread safe socket", I would recommend this approach. We would need to create inproc sockets and store them as ThreadLocal. This would then properly abstract out each socket for each thread.

+1, also from experience developing applications using ZeroMQ. 

The "each thread has its own inproc socket" model is really nice and we
should emphasise it more. It leads to developing your applications
around messaging and concurrency, and IMO is a much more elegant way of
dealing with concurrency than the "old school" locks and shared state
model.

Can you elaborate on why such a socket would have to be stored as
ThreadLocal? Given that in ZeroMQ a single listening (bound/connected)
socket can have many other sockets connected to it, if threads A, B, C
want to talk to thread D then A, B, C each have their own socket
and all connect to D's inproc:// endpoint.

-mato
-- 
Martin Lucina <martin at lucina.net>