[zeromq-dev] Thread-safe sockets (cont.)

[Justin Karneges]

I apologize for jumping in mid-conversation, but I see two thread-safety 
goals:

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 
socket accesses.

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 
true?

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 ...
> 
> 
> Marten
> 
> 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
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev