undefined | Better HN

0 pointschipdart1y ago0 comments

> So... What is it seeking to optimize?

The goal is to maximize the number of tasks you can run concurrently, while imposing on the developers a low cognitive load to write and maintain the code.

> Why did you need a thread pool before but not any more?

You still need a thread pool. Except with virtual threads you are no longer bound to run a single task per thread. This is specially desirable when workloads are IO-bound and will expectedly idle while waiting for external events. If you have a never-ending queue of tasks waiting to run, why should you block a thread consuming that task queue by running a task that stays idle while waiting for something to happen? You're better off starting the task and setting it aside the moment it awaits for something to happen.

> What resource was exhausted to prevent you from putting every request on a thread?

0 comments

riku_iki1y ago

> why should you block a thread

if creating gazillion threads on modern hardware is super cheap why not? I have transparency and debuggability what threads are running, can check stacktrace of each and what are they blocked on.

virtual threads adds lots of magic under the hood, and if there will be some bug or lib in your infra with no vthreads support it is absolutely not clear how to debug it.

chipdartOP1y ago

> if creating gazillion threads on modern hardware is super cheap why not?

Virtual threads are a performance improvement over threads, no matter how cheap to create threads are. Virtual threads run on threads. If threads become cheaper to create, so do virtual threads. They are not mutually exclusive.

Virtual threads are on top of that a developer experience improvement. Code is easier to write and maintain.

Virtual threads improve throughput because the moment a task is waiting for anything like IO, the thread is able to service any other task in the queue.

riku_iki1y ago

> Virtual threads are on top of that a developer experience improvement. Code is easier to write and maintain.

except now you need to prove somehow that all 100 libs in your project support virtual threads.

> Virtual threads improve throughput because the moment a task is waiting for anything like IO, the thread is able to service any other task in the queue.

from reading similar discussions, linux for example doesn't have true IO async API, you just push lock of Java thread to lock of thread in the kernel

1 more reply

stoperaticless1y ago

Each thread adds overhead.

Some usage types don’t care, some do.

From what I gather virtual threads are an alternative to “callback-hell” (js) or async coloring (python).

riku_iki1y ago

> Some usage types don’t care, some do.

I suspect if you care about threads overhead, you won't pick Java, because there will be overhead in other areas too

> From what I gather virtual threads are an alternative to “callback-hell” (js) or async coloring (python).

there is also existing ExecutorService and futures in Java

1 more reply

j / k navigate · click thread line to collapse

0 comments

riku_iki1y ago

> why should you block a thread

if creating gazillion threads on modern hardware is super cheap why not? I have transparency and debuggability what threads are running, can check stacktrace of each and what are they blocked on.

virtual threads adds lots of magic under the hood, and if there will be some bug or lib in your infra with no vthreads support it is absolutely not clear how to debug it.

chipdartOP1y ago

> if creating gazillion threads on modern hardware is super cheap why not?

Virtual threads are on top of that a developer experience improvement. Code is easier to write and maintain.

Virtual threads improve throughput because the moment a task is waiting for anything like IO, the thread is able to service any other task in the queue.

riku_iki1y ago

> Virtual threads are on top of that a developer experience improvement. Code is easier to write and maintain.

except now you need to prove somehow that all 100 libs in your project support virtual threads.

> Virtual threads improve throughput because the moment a task is waiting for anything like IO, the thread is able to service any other task in the queue.

from reading similar discussions, linux for example doesn't have true IO async API, you just push lock of Java thread to lock of thread in the kernel

1 more reply

stoperaticless1y ago

Each thread adds overhead.

Some usage types don’t care, some do.

From what I gather virtual threads are an alternative to “callback-hell” (js) or async coloring (python).

riku_iki1y ago

> Some usage types don’t care, some do.

I suspect if you care about threads overhead, you won't pick Java, because there will be overhead in other areas too

> From what I gather virtual threads are an alternative to “callback-hell” (js) or async coloring (python).

there is also existing ExecutorService and futures in Java

1 more reply

j / k navigate · click thread line to collapse