> > > 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.
One use case is when you write a library on top of zeromq that runs user code (maybe in form of callbacks) on threads A, B and C. Those callbacks needs a way to obtain a socket connected to D in order to reply. It could be passed to them as an argument, and they can pass that socket again to each function that they are calling, making the API more explicit than what you'd like. So you want to make it a bit easier on your users by having your library figuring out the right socket to use from the identity of the currently running thread.
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
