On 03/02/2012, at 2:32 PM, Chuck Remes wrote: > I can't imagine how it would be done cleanly. I haven't thought about it as > deeply as you, but in my experience this will be very difficult if not > impossible to achieve. I welcome being proven wrong. :)
Can you explain why simply setting a mutex at the start of every C API call, and releasing it at the end, would not work? the mutex object would live in the socket. Given that, making the set and release of the mutex conditional on a flag, also in the socket, could be done, and the flag can clearly be inherited from the context that creates it. > >> Of course I'm not even going to look at the code if there's no demand for >> thread safe sockets. > > I have yet to see anyone in this thread demand it. This lack of demand may > yet save you from the work! True :) However there's a caveat: people regularly say "I don't need that, I have worked without it, why would I need it". They say it because they don't have the alternative available to try. Why would you need C++? People have been programming successfully in C for ages and ages! Actually .. no they haven't. They just think they have been, they have no idea at all how bad their code is and how inefficient they are by comparison .. because they have no comparison. > >> I also asked a question earlier that didn't seem to get answered: what is the >> attitude introducing a dependence on a foreign library? (Source can be >> included >> in zmq without licence issues). In this case, Judy, since that determines >> the overhead. > > I am not a license (or a British licence) expert. I'll defer to others to > chime in. I'm saying there's no licence issue (I know the developer and he can make sure there is no issue and I feel would do so!). The fundamental question is whether ZMQ should have a third party library in it. There's good reason to NOT do this. Felix has the policy of not depending on external third party libraries, we DO use Judy, so we actually "submodule" the sources and build it as part of Felix. But it is still a 3PL in that if it had a bug there's no way I could fix it. It's a risk. I took it because its used in the GC to track every memory allocation so we need the best available data structure, and that is appears to be Judy1/JudyL arrays. If the decision is not to depend on any 3PLs such as Judy I can understand and live with the consequences: homebrew code will never be as good, but it is maintainable. I just don't want to have a go at a patch where *I* would use Judy and find it is rejected because of that, when I could have used a STL::map instead. Or where using an STL::map would make the performance untenable (Judy arrays are an order of magnitude or more faster for this particular requirement). So I'd rather "prune" the possible implementations before starting on one :) -- john skaller [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
