[zeromq-dev] C++ assertion failed with Java client

[john skaller]

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
skaller at users.sourceforge.net