[zeromq-dev] Thread Safe sockets

[Martin Sustrik]

On 02/07/2012 09:57 AM, Chuck Remes wrote:

> While watching this thread, I can't help but think that you wish 0mq
> was a *much different* library than it is. I'm hoping that sustrik
> stays engaged with it at some level to indicate how much is feasible
> for his long-term vision (getting 0mq into the kernel) and how much
> of it is superfluous to that vision.
>
> I think it will be quite difficult to accommodate your proposed
> changes while providing any kind of backward compatibility. But, I
> look forward to the continued discussion.

Well, my opinion is as follows:

1. 0MQ protocol right now conflates two layers of the stack. First 
there's the "scalability" protocol that defines messaging patterns, then 
there's  a simple presentation (L6) protocol that allows user to split 
one message into several pieces (this is similar to protocols like XML 
or JSON, albeit somewhat simpler).

2. If the two layers were properly separated, we could separate the 
presentation layer into a separate library built on top of 0MQ and 
forget about it. The lower layer in turn would work only with 
single-part messages and thus not exhibit the problem we are discussing now.

3. Doing 2. is not possible because of backward compatibility concerns. 
So, the following discussion is purely theoretic.

4. Once there are no multi-part messages, there's nothing preventing the 
sockets to be threads safe. I am not sure whether POSIX requires sockets 
to be thread-safe, but all the implementations and had the pleasure to 
deal with _are_ thread safe. Thus, when considering the move of 0MQ-like 
functionality into kernel, the thread-safeness becomes an expected feature.

5. That being said, using single socket from multiple threads is not a 
good design decision. It breaks the model of threads viewed as 
stand-alone state machines communicating with the outside world via 
exclusively owned sockets.

6. There may be some strange use cases where thread-safety is actually 
needed. However, I haven't seen such a use case myself and so far nobody 
in this thread was able to describe one. Maybe we should rather focus in 
documenting such a use case. That would give us much cleaner picture of 
what's actually needed.

Martin