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

[Chuck Remes]

On Feb 2, 2012, at 8:23 AM, john skaller wrote:

> Oh, I grok the rule just fine, but perhaps you don't perceive the impact on 
> frameworks where the client doesn't have that kind of control .. or simply
> doesn't care ..
> 
> Felix handles several *million* threads. (TCP) socket I/O is done the same
> way ZMQ does it: in a background thread. ZMQ sockets in Felix currently
> block the containing pthread, which is no good. 
> 
> To fix that the I/O will be lifted into a background thread. So it is *guaranteed*
> the I/O will happen in a different thread to the one that created the socket :)
> 
> But still I doubt any extra locks are required at present since ALL the I/O is done
> in the background. OTOH if I do what 0MQ does -- and provide more than one
> background thread, I may need interlocking.
> 
> It's likely applications such as a webserver will have a set of waiting
> fibres (one per connection or more), and they'll be farmed out to
> an arbitrary p-thread allocated from a pool. In that case, how can
> the "client" possibly obey "the Rule" since they have no control
> over which p-thread does the work?
> 
> if you're stuck writing applications in C from the ground up you may well
> have the design control to obey "the Rule" but you can't assume people
> using advanced languages or frameworks, including stuff like Python,
> will have that kind of control. 0MQ isn't the only way to make multi-threaded
> programming safer. It needs to be able to fit in with other technologies.

John,

I am glad you have joined the 0mq community. It thrives on new ideas, "fresh blood" and motivated programmers. You are all three.

But (you knew there was a "but" coming, right?) you still don't grok it.

When I first wrote the Ruby bindings, I used it as an exercise to learn the library. I translated a few of the examples, got them running and was pretty pleased with myself. Then I decided to write a real app using the bindings. At least 6 months later, it occurred to me that without that first "real and non-trivial" application, I didn't really know 0mq at all. I certainly was comfortable with the concepts and their usage, but trying to get the code to work in a useful manner was the acid test.

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.

What's worse is that you could solve the issues you mention above without a single change to libzmq. As the author of your binding, you can choose to present any reasonable api to your users. That facade can perform all manner of locking (memory barriers) to make massively-multithreaded code safe and to shield your Felix users from the underlying complexity. Try to do this with the current constraints that libzmq places on you and see how far you get. 

At this time, we have bindings for every major language (C, Java, Ruby, Python, LISP, OCaml, Lua, Erlang) many of which have runtimes that have additional limitations when using C-based libraries like libzmq. If those myriad runtimes and languages can somehow support libzmq safely and efficiently *without changing* libzmq, then I think you can figure out how to do the same for Felix.

Please, please finish your bindings and *write at least one real non-trivial application* before you form too many strong opinions about how libzmq should change.

I hope you don't take my suggestion as being rude. I do not intend it that way. Also, don't abandon us. We need you and others like you, but we need you better informed.

cr