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 <[email protected]> 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.
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
