[zeromq-dev] Thread Safe sockets
sustrik at 250bpm.com
Tue Feb 7 02:16:45 CET 2012
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.
More information about the zeromq-dev