2

In the JVM, threads are just thin wrappers around native OS threads. And native OS threads have a high footprint and creating them/switching between them is not a lightweight task. To overcome this downside the asynchronous NIO in JDK was brought in which returns the thread to the thread pool while the task is waiting. Once the task is over, another thread from the thread pool is picked up to carry on the task.
How does the system know that the task is over? The task could be waiting for a response from an HTTP server. But since the thread has been returned to the thread pool, who interrupts the CPU to notify that the task is done and the work can be continued?

Ashwin
  • 12,691
  • 31
  • 118
  • 190
  • Does this answer your question? [How non-blocking API works?](https://stackoverflow.com/questions/41227272/how-non-blocking-api-works) – David Haim Dec 29 '20 at 10:58
  • @DavidHaim The answer does touch upon the topic but does not answer the specific question of `how is task completion notified` – Ashwin Dec 29 '20 at 11:14
  • How the kernel knows an IO operation is done? well, it's its job.. it knows everything that happens in your OS – David Haim Dec 29 '20 at 11:16
  • @DavidHaim according to [this](https://gist.github.com/djspiewak/46b543800958cf61af6efa8e072bfd5c), there is a separate thread pool which takes care of all blocking operations. – Ashwin Dec 29 '20 at 11:47
  • This looks like a general recommendation for developers how to design their concurrency. this recommendation is definitely not how the JVM is working inside, nor it says so. – David Haim Dec 29 '20 at 11:49
  • @DavidHaim true, it is a general recommendation and this kind of design is followed in [cats-effect](https://github.com/typelevel/cats-effect) and is known to be very performant. I assumed that this is how java NIO would also work – Ashwin Dec 29 '20 at 11:58

1 Answers1

1

Threads are not returned to the thread pool.

If you are referring to Selectors then you have a single thread that can serve many connections. This is called multiplexed IO and on Linux the Linux epoll system is under the hood. This thread is your own to control.

So your thread runs in some event loop over the selector. It will wait if there is nothing ready (e.g. data available for reading in a socket) and once the data comes in, the selector will wakeup the thread, and the thread can then deal with every selection key that is ready for processing.This way a single thread can process a bunch of connections concurrently.

Pseudo code:

for(;;){
   int count = selector.select();
   if(count>0){
       for(SelectionKey key: selector.getReadySet()){
         process(key);
       }
   }
}

And the above loop you run in your own thread.

pveentjer
  • 10,545
  • 3
  • 23
  • 40