[zeromq-dev] Thread Safe sockets

[Nadav Samet]

Hi John,

Your argument is valid, but it can be equally applied to std::queue,
std::map or any other stateful object. As a single data point, the C++ STL
standard chose that the clients will provide the locking. There are various
reasons in http://www.sgi.com/tech/stl/thread_safety.html, although I
believe their performance argument does not apply in our case. I tend to
agree with them that wrapping classes in a thread-safe manner on the client
is easy and can provide more encapsulation.

If libzmq is changed such that sending/receiving individual frames is no
longer possible for clients, then I think it's reasonable to have locking
inside zeromq. But as long as users talk to the API in terms of single
frames, the current implementation does not really provide thread safety
and might cause confusing problems to users.

On Mon, Feb 6, 2012 at 3:57 PM, Joshua Foster <jhawk28 at gmail.com> wrote:
>
> 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, this approach works well for me (using TLS). It would be useful to have
this functionality standardized in a library.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120206/4c5bcfab/attachment.htm>