On Feb 3, 2012, at 10:05 AM, john skaller wrote: > >> A mutex works fine with a 0mq socket so adding one to the socket itself >> would also work. I just don't think it would perform well plus everyone >> would have to pay that price even if they didn't need it. Yuck. > > I have implemented (but not tested) thread safe sockets, available in Pull > request.
You're lucky that the lack of tests isn't a problem for merging to master. We do require tests for patches to stable branches. If I have time today I'll try and get this merged (but I'm leaving town for a few days so I might not get to it until Monday). > YMMV. Perhaps it should go in a branch or not get pulled at all. > > One function is added to the C API: > > zmq_init_thread_safe (nthreads) > > If this function is used, all C API socket functions on any socket spawned by > that > context will be wrapped in a mutex. > > There is no semantic impact on any existing C or C++ code. > Calls internal to ZMQ C++ code base are not affected. > > Cost, memory, everyone pays: one bool in context and one bool and one mutex > in socket. > Cost, speed, everyone pays: currently two tests in every C API socket call. > Could be reduced to one at he expense of duplicating the C++ method call. > > There is no way to selectively turn on or off socket thread safety from the C > API. > > BUGS: I deliberately used a "set" method to allow the C++ constructor > arguments > to remain unchanged: attempting to provide minimal interference to any > existing ZMQ core C++ code. > > This required exposing a "set" method on the sockets. > It is NOT safe to call that method, but I can't protect it or the C API > wouldn't > be able to access it. This should be fixed if the patch proves useful. > > I have no real input on its utility. It may help in some bindings such as > Java. > It may also be useful in "utilities" where functionality and rapid prototyping > are more important than performance. We'll let the community decide. In my role as a maintainer, I have no opinion on patches. :) cr _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
