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" <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
