Should thread blocked by java NIO Selector.select() be considered waiting or running

Question

The documentation of selectorObj.select() method states

This method performs a blocking selection operation. It returns only after at least one channel is selected, this selector's wakeup method is invoked, or the current thread is interrupted, whichever comes first.

I understand the documentation The thread that is blocked by select method, shouldn't be waiting? When I run profiler I see the thread is in run mode instead of wait state.

Although, I accept that, it is not mentioned that the thread should be in wait state, but my assumption is that till the signal dispatcher thread provides some input regarding any activity on channel registered with selector; the thread should be in wait state.

Please provide me some help as to why my assumption could be wrong.

Answer 1

When the thread is blocked in an I/O call, it is still running as far as Java thread is concerned.

Most profilers simply show thread state, which is defined as,

• NEW A thread that has not yet started is in this state.
• RUNNABLE A thread executing in the Java virtual machine is in this state.
• BLOCKED A thread that is blocked waiting for a monitor lock is in this state.
• WAITING A thread that is waiting indefinitely for another thread to perform a particular action is in this state.
• TIMED_WAITING A thread that is waiting for another thread to perform an action for up to a specified waiting time is in this state.
• TERMINATED A thread that has exited is in this state.

As you can see, thread's WAITING/BLOCKED state has nothing to do with I/O.

Answer 2

Normally the select operation invokes the poll(...) system function.

select() provides the kernel with a list of file descriptors that it needs to monitor for read/write/error conditions as well as a timeout value. The kernel registers the process/thread with the associated channel's select function and puts the process/thread to sleep. Once the associated channel is ready or a timer has been expired, the kernel wakes up the registered process/thread. Note that this thread is the kernel thread and not the java application thread.

I do not see a reason for the thread doing select to be in WAIT state (Unless the implementation of the Selector returned by the Selector provider explicitly did a wait in the select() function).