I think zmq should maintain a single, consistent, opinion on concurrency. In a typical application right now, one federates messages to multiple [worker] threads using an inproc device.
It might be slightly more work than a simple synchronized queue, but otoh you're using zmq for a reason - typically to avoid locks, scale easily and to keep things simple. I quite enjoy this model, and it encourages sound reasoning about concurrency. I might misunderstand, but it seems counterproductive to add a separate mode of operation where a zeromq socket is "thread-safe by default", and have it only be distinguishable by a flag. If anything, it would be beneficial to actively *prohibit* access to sockets from "other" threads to enforce safety. Just my thoughts... On Fri, Feb 17, 2012 at 08:07, Justin Karneges <jus...@affinix.com> wrote: > 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@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
