Your example code just shows that 'thread per request' design is bad, not that fibers are good. In fact fibers just shift bounds where inherent limitations of such a design affect application.
Actually I tried to show that how JAVA codes can benefit from fibers by very small changes in the code and how structured concurrency helps in writing cleaner concurrent code.
Your example code just shows that 'thread per request' design is bad
Well, my example shows or at least tries to show that the design itself was not inherently bad, just the current implementations had a huge overhead in terms of context switch and memory footprint that are addressed by Fibers!
If you could think of any example to show the fiber limits, please share it we me. So that I can reflect its result in my post as well.
Yes, you did show that it is possible to preserve synchronous processing model with fibers. But I believe that synchronous processing model is the thing of the past and preserving it has no value.
As for design issues. Regardless from the way threads/fibers are managed, there is still memory and CPU overhead related to context switching at the points where blocking call is involved. In contrast asynchronous model has almost zero extra overhead. So, instead of try to extend life of the inherently flawed processing model, I think it is better to spend efforts to make asynchronous processing more convenient for developers.
I'm pretty sure that synchronous model is the main obstacle on the wider use of asynchronous processing. Another one is the lack of convenient farmeworks/libraries. Existing ones trying to preserve too much things Java developers are used to. For example, CompletableFuture would be Java name for Promises, but in attempt to preserve exceptions and other redundant stuff, it's API made so complex and inconvenient that nobody even bothers to use it.
I wonder what asynchronous model you are referring to that has almost zero extra overhead? AFAIK most of the async models have considerable amount of context-switches, and sometimes even too much alexn.org/blog/2017/01/30/asynchro...
Perhaps the model with very few context-switch is the event loop. simple to use but hard to utilize computation resources machine have.
Hopefully in near future we can run real benchmarks and compare the result or these 2 programming models. I don't say Fibers would be the winner, however I doubt its overhead would be significantly more than asynchronous model.
Classic Reactor pattern has very few context switches. Multithreaded implementations of this pattern also exists (Vert.x, for example).
Thanks for the link, I'll take a look deeper, but at first look seems issues described there are mostly related to particular Scala implementations.
As for performance benchmarking. There is well established benchmark - techempower.com/benchmarks/ . Simplest approach is to implement fiber-based version of this benchmark. There are several other implementations available, so it shouldn't be hard to implement another one.
Implementations which utilize asynchronous processing are already present in benchmark and usually are at the top of the list. Note, that this is not so for Akka-based implementation which suggests that something is wrong with either particular implementation or with Akka itself.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your example code just shows that 'thread per request' design is bad, not that fibers are good. In fact fibers just shift bounds where inherent limitations of such a design affect application.
Actually I tried to show that how JAVA codes can benefit from fibers by very small changes in the code and how structured concurrency helps in writing cleaner concurrent code.
If you could think of any example to show the fiber limits, please share it we me. So that I can reflect its result in my post as well.
Yes, you did show that it is possible to preserve synchronous processing model with fibers. But I believe that synchronous processing model is the thing of the past and preserving it has no value.
As for design issues. Regardless from the way threads/fibers are managed, there is still memory and CPU overhead related to context switching at the points where blocking call is involved. In contrast asynchronous model has almost zero extra overhead. So, instead of try to extend life of the inherently flawed processing model, I think it is better to spend efforts to make asynchronous processing more convenient for developers.
I'm pretty sure that synchronous model is the main obstacle on the wider use of asynchronous processing. Another one is the lack of convenient farmeworks/libraries. Existing ones trying to preserve too much things Java developers are used to. For example, CompletableFuture would be Java name for Promises, but in attempt to preserve exceptions and other redundant stuff, it's API made so complex and inconvenient that nobody even bothers to use it.
I wonder what asynchronous model you are referring to that has almost zero extra overhead? AFAIK most of the async models have considerable amount of context-switches, and sometimes even too much
alexn.org/blog/2017/01/30/asynchro...
Perhaps the model with very few context-switch is the event loop. simple to use but hard to utilize computation resources machine have.
Hopefully in near future we can run real benchmarks and compare the result or these 2 programming models. I don't say Fibers would be the winner, however I doubt its overhead would be significantly more than asynchronous model.
Classic Reactor pattern has very few context switches. Multithreaded implementations of this pattern also exists (Vert.x, for example).
Thanks for the link, I'll take a look deeper, but at first look seems issues described there are mostly related to particular Scala implementations.
As for performance benchmarking. There is well established benchmark - techempower.com/benchmarks/ . Simplest approach is to implement fiber-based version of this benchmark. There are several other implementations available, so it shouldn't be hard to implement another one.
Implementations which utilize asynchronous processing are already present in benchmark and usually are at the top of the list. Note, that this is not so for Akka-based implementation which suggests that something is wrong with either particular implementation or with Akka itself.