Hi everyone,
I am still having a hard time to understand the difference between concurrency and asynchronous.
I have asked the question about how we can achieve highly concurrency in elixir here and all the answers really helps a lot.
But, I recently view the presentation about modern java non-blocking library like Reactor or RxJava. I think they are non-blocking java library and helps to use resource more efficiently and asynchronously.
My understanding about reactor is as follow:
- They also use 1 thread for each cpu cores
- Use event loop mechanism, ie. when there’s a request come in, they do the book keeping (register request and its callback) and move it to the waiting queue so that the system can continue serving more request. When there’s result comeback then the callback is put in the event queue and processed by event loop.
So basically I think it was also like elixir where one scheduler thread run processes when needed ?
So I think reactor is also highly concurrent if the “task” is IO-bound ? And in this case, elixir and java reactive library is the same ?
And elixir only prove more concurrency when the “task” is cpu-bound ? I am still not sure how the event loop will behave in that situation because I think the code in the callback should be very quick to avoid blocking the entire system.
Another question is that library like reactor support the reactive streams specification. I also read in one of the blog post saying that otp which is based on actor model is also provide built-in support for reactive streams. Can you help to explain that ?
I would appreciate your feedback on this questions. Thank you so much?
I have not used java in a long time. If java reactor works the way you say it does, it is in many ways similar to elixir. But I think the difference is this: Elixir is designed from the bottom up to work with its “event loop”. If you write a long function in elixir, the system knows exactly where to interrupt this function and move on to work on another function. Can you say the same for Java? Can you say with confidence that whatever mechanism reactor uses to decide when to take control away from one task plays nicely with the entire JVM ecosystem?
OTP is not based on the actor model, but it looks a lot like the actor model. It’s so close that it’s often “good enough” to think about it that way. But it’s important to remember, the actor model was designed as a way to organize your code, and erlang processes were designed as a way to organize your failure domains. These are different in very important ways. If you try too hard to follow the traditional actor model in your BEAM program design, you are very likely to wind up with bottlenecks. If you don’t care about bottlenecks (which you don’t need to for some tasks), then that might be okay too (I watched a fantastic talk by Laura Castro where she designed a very actor- heavy system, and you know what, it was totally fine, for her purposes). There aren’t any absolute answers. Sometimes the JVM is going to be better than the BEAM, but I personally wouldn’t want to spend my time coding in the JVM.
Maybe one way to put it is this: I write code in the BEAM because I care about my customers and I like to sleep soundly at night =D. There is no way to measure that.
4 Likes
