Hacker News Reader

Comment by riku_iki | Hacker News Reader

I think what you are describing is API for manual scheduling: you call sleep() to give up control to scheduler.

With tasks/futures you supposed to submit another task to pool which will wake up after certain time.

Both are "green threads" with manual scheduler (you need to make explicit call to give up control to scheduler) but different API.

View on HN

Thread.sleep on a platform thread takes that thread out of action until the sleep ends. If an executor with 10 threads got 10 tasks that all called Thread.sleep(1000000) then it can run no more tasks until one of the threads wakes up.

When a virtual thread sleeps or blocks on IO it is unhooked from the underlying platform thread so another virtual thread can run. You can have an almost unlimited number of virtual threads multiplexed over a small number of carrier (platform) threads. Hence M:N

In your view advancement is that in "green threads" they overloaded Thread.sleep(..), so it doesn't call real Thread.sleep() but doing something like Futures + ExecutionService underneath instead.

Java already had tons of non-blocking io/http and many other frameworks without "green threads" but using futures and executionservice. Green threads look like syntactic sugar.

I think Thread.yield() would do that?

Thread.yield() is very weird, and something I'd not advise using aside spin lock with backoff. It's OS dependent, and if may just bounce to the OS and back, continuing the current execution.

Reply on news.ycombinator.com