The Unscalable, Deadlock-Prone, Thread Pool

Re:The Unscalable, Deadlock-Prone, Thread Pool by spricket on Tuesday February 26, 2019 @07:12PM (#19259707)

This feels language specific. Java has excellent thread support for example, it's quite hard to build an application that deadlocks.

Thread-per-request is how everything used to be done. Most languages switched to pools because of huge fork/threading overhead.

Other languages have embraced async programming to deal with these issues, and use thread-per-core. But that introduces some fairly awkward coding constructions itself.

I believe the best approach is transparent fiber support. Java's Project Loom is a very ambitious attempt at this. And if you're okay with a "hacky" solution, you can already use fibers with Quasars code generation.

In java at least, the biggest barrier to fiber support is existing libraries not supporting it (looking at you JDBC/JPA). Hopefully project loom will make existing code work with little or no modifications

[ Parent | on HN ]

Re:The Unscalable, Deadlock-Prone, Thread Pool by xenadu02 on Tuesday February 26, 2019 @07:40PM (#19259861)

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.

[ Parent | on HN ]

Re:The Unscalable, Deadlock-Prone, Thread Pool by agumonkey on Tuesday February 26, 2019 @07:51PM (#19259917)

I'd love to learn how to design this way, any reading ?

[ Parent | on HN ]

Re:The Unscalable, Deadlock-Prone, Thread Pool by ioquatix on Tuesday February 26, 2019 @09:09PM (#19260270)

I wrote a full stack implementation for Ruby: https://github.com/socketry/async

Come and chat here: 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.

[ Parent | on HN ]

Re:The Unscalable, Deadlock-Prone, Thread Pool by balfirevic on Wednesday February 27, 2019 @07:43AM (#19262859)

> I believe the best approach is transparent fiber support. Java's Project Loom is a very ambitious attempt at this.

I guess the time was due for us C# developers to have something to be envious of in Java world :)

I'm really disappointed that .Net world went the async/await route. This blog post best describes why: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

[ Parent | on HN ]

Re:The Unscalable, Deadlock-Prone, Thread Pool by spricket on Friday March 01, 2019 @10:52AM (#19281731)

I agree. C# is wonderfully designed, only reason I haven't switched is the huge number of wonderful libraries available in java.

Also sad that C# went asynchronous. I mean, it works great, and it's better than what Java has now, but it's not backwards compatible like I expect fibers to be. With how many third party libraries we pull in, this is a gigantic selling point

[ Parent | on HN ]

Re:The Unscalable, Deadlock-Prone, Thread Pool by aardvark179 on Tuesday February 26, 2019 @08:42PM (#19260159)

It is certainly the plan that existing code should work with little or no modification. Alan Bateman has been doing great work fixing the standard library to allow this, though there will be some limitations round JNI and other areas.

If you need to stop too many fibers running at once then this should be very simple to implement using any of java.util.concurrent’s mechanisms, if they block the fiber it will be parked and another can be run.

[ Parent | on HN ]