3 ms·
The issue the OP is addressing covers your comment quite well. Async continuations, coroutines, and fibers can all race ahead and exhaust memory/DB connections/
by xenadu02 8y ago
The issue the OP is addressing covers your comment quite well. Async continuations, coroutines, and fibers can all race ahead and exhaust memory/DB connections/network sockets, or just saturate the IO subsystem. In a multi-step process this can easily lead to starvation in downstream steps.
The point of structuring an application this way is to prevent any one stage of your pipeline from consuming too many resources or stalling other stages (or just hammering some other system with requests that will inevitably timeout).
I don’t see how your comment about fiber support in Java applies.
- agumonkey 8y agoI'd love to learn how to design this way, any reading ?
- ioquatix 8y agoI wrote a full stack implementation for Ruby: https://github.com/socketry/async https://github.com/socketry/async Come and chat here: https://gitter.im/socketry/async https://gitter.im/socketry/async TruffleRuby folks are trying to support us using native fibers in the JVM, but I'm not sure when that will be working.