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

[Gleb Peregud]

Looks like Felix has processes/threads/fibers similar to Erlang processes.
John, you could check erlzmq2 bingings to see how it is done there
On Feb 2, 2012 3:45 PM, "Chuck Remes" <cremes.devlist at mac.com> wrote:

>
> 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
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120202/3f09761f/attachment.htm>