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

[Chuck Remes]

On Feb 2, 2012, at 7:49 PM, john skaller wrote:

> 
> On 03/02/2012, at 7:36 AM, Chuck Remes wrote:
> 
>> 
>> On Feb 2, 2012, at 2:23 PM, Pieter Hintjens wrote:
>> 
>>> On Thu, Feb 2, 2012 at 3:44 PM, Chuck Remes <cremes.devlist at mac.com> wrote:
>>> 
>>>> As far as I can see, you haven't even finished your Felix bindings but you are participating in at least 3 threads on this list with very strong opinions on how to change libzmq.
>>> 
>>> Oh, I think you're explaining it wrong... :-)
>>> 
>>> We welcome all patches.
>> 
>> Following your lead on this, all I can say at this point is that I think it's very difficult to create a patch that does what Mr. Skaller suggests. Actually, it's probably impossible.
> 
> I  know  it's difficult sometimes to explain negative things, but can you indicate
> why, when one respondent considers wrapping the API with locks is easy enough,
> you consider simply embedding the locking inside the functions impossible?

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. :)


> 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!

> 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.

cr