[zeromq-dev] Thread-safe sockets (cont.)
justin at affinix.com
Fri Feb 17 08:07:45 CET 2012
I apologize for jumping in mid-conversation, but I see two thread-safety
1) 0MQ has no built-in locks on sockets. Applications may use a socket in
different threads provided the application itself uses its own locks around the
2) 0MQ has its own locks built-in, so you can use a socket in different threads
and the application does not need its own locking.
As I understand it, the current stable 0MQ does not even allow #1. At least,
I have read documentation stating that a socket should not be used except in
the thread it was created in, meaning sockets have thread-affinity. Is this
I personally would like to see #1 solved if it has not been already. I think
it should "just work", but offering a function to change thread affinity of a
socket would be acceptable. Otherwise, 0MQ is "thread impossible", which to
me is much worse than "not thread safe". :)
I have no need for #2 and I think it's overkill. The only justification I can
see for it is if 0MQ is trying to emulate posix/kernel behavior and this is a
necessity in its long term goals.
On Thursday, February 16, 2012 10:53:19 PM Marten Feldtmann wrote:
> I am by far no expert in 0MQ, but actually the question of thread-safe
> socket is no question any more for me. It has been written in the
> documentation in a clear way, that one should not use sockets from
> different threads. Over the last weeks - and due to a question from me -
> it was in a more detailed way explained, what is allowed to do and what
> not. These informations should be added to the documentation.
> I've no problem to follow this guideline in my Smalltalk language
> binding. Its ok and I can work with it and I offer a thread safe
> interface to the 0MQ library. When people starts working around my
> "official" language binding - ok, then its their fault. I can not and
> would not like to forbid this - I assume, that others also might know
> how to use the 0MQ library. Therefore: leave the decision to the end
> user and give them enough information so that it can make their own
> decisions based o this free available information.
> I like 0MQ because it has such a small C-level API and it is easy to
> use. The examples guides are well done and show how to use it.
> Perhaps thread-safe sockets are a nice marketing idea. Some people might
> think, that this is an absolute must to have - and without that a
> library is not a reliable piece of software. It is perhaps the same as
> thinking, that dynamic typed languages are a regressive step in CS. At
> least this last idea is simply wrong and has been shown over the last 50
> years in CS.
> > There is an analogue in Posix: optional locking. It's fairly useless.
> > Because anyone can write into a locked region of a file by ignoring
> > the locks.
> This optional locking is quite a good design pattern: Perhaps the base
> system contains an error and the strict locking prevents you from doing
> the last emergency execution step. Its then always good to have the
> choice (thats the keyword in building libraries) of turning of this
> locking ...
> Am 17.02.2012 02:56, schrieb john skaller:
> > It's not entirely useless but in todays world software is so complex
> > people want rigid guarantees of correctness for some things, because
> > there are always a heap of other things where there are no assurances:
> > [casts in C .. dynamic typing in web applications OMG what a regressive
> > step in CS]
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev