On 02/04/2015 02:34 PM, Maurice Barnum wrote: > On Tuesday, February 3, 2015 2:05 AM, Pieter Hintjens <[email protected]> wrote: > >> I've written up my understanding of this thread: http://hintjens.com/blog:84 >> Thread safety would solve the perennial problem of sending data via >> ZeroMQ, from short-lived threads. Performance in many cases would go >> up, not down. We see way too many apps that create/connect a socket >> for every message they send. >> Apart from that I agree that thread safety is a weird thing and only >> worth doing in very specific cases (ZeroMQ contexts and sockets seem >> to be good candidates). > For sockets, I've several times have wanted to integrate with a library that > uses callbacks on an implementation-defined thread (aka, "not mine"). I want > to take the data supplied with the callback and enqueue it to a worker that > uses minimal (preferably no) shared state with the rest of the application. > Since ZeroMQ sockets are not thread safe, I have to build my own queuing > mechanism and either not use ZeroMQ for this part of the application or live > with the complexity of a hybrid solution. > _______________________________________________ >
I have run into the same issue with library callbacks. Also, thread safe sockets would be useful when sharing a single socket within a web container (eg, Tomcat, etc.) A common case is to want to dispatch a message to a socket from a container thread. Since the socket is not thread safe I have to hack around it (typically creating an iproc socket per request). This is probably not very efficient and it's definitely kind of ugly. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
