[zeromq-dev] Notes from a hackathon

Colin Ingarfield colin at ingarfield.com
Wed Feb 4 21:53:16 CET 2015

On 02/04/2015 02:34 PM, Maurice Barnum wrote:
> On Tuesday, February 3, 2015 2:05 AM, Pieter Hintjens <ph at imatix.com> 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.

More information about the zeromq-dev mailing list