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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
