On 02/02/2012, at 10:36 PM, Martin Lucina wrote: >> Q: is it technically feasible to make a thread-safe wrapper around 0MQ >> sockets? > > Sure, chuck a bunch of locks around socket-related calls? A mutex implies a > full memory barrier, so things should work OK at least on cache-coherent > architectures. > > Performance will take a nose-dive of course, but if that is not a concern, > go for it ... >
I would put these directly in the official ZMQ C API. The rationale is that ZMQ's own rationale is that you can program with ZMQ instead of using all those nasty locks, share memory barriers, and all the other things that make multi-threaded programming a nightmare. In Felix I have a garbage collector: flx_collector_t and a second collector flx_ts_collector_t which is a thread-safe wrapper around the first one: both are derived from flx_gc_t abstract class in the C++ code. The wrapping should be done in C++ and exported to C, not in C around the C API. IMHO. Which means it has to be part of the ZMQ C API standard. The reason is I think (a) the locking can be made somewhat "conditional" and (b) because of the particular structure of ZMQ other techniques which can avoid mutex or semaphores may be used. (c) it makes the Windows and Posix usage of ZMQ the same in an environment where 0MQ sockets are used in several threads, rather than forcing the client to use OS local locking techniques. It's not clear if the "right way" is to have a zmq_context, and a zmq_ts_context, so that if you make the latter all the socket objects spawned off it are thread safe. This is clearly simpler and avoids changes to the other functions, but it provides less control and therefore imposes an overhead. -- john skaller [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
