After reading the code:
The serverSock
object is listening for incoming connections is blocking. The socket
channel object associated with its new accepted connection is the one that implements a non-blocking I/O.
The Acceptor class
that is a thread that listens for incoming connections has the following definition in its run
method:
protected class Acceptor extends AbstractEndpoint.Acceptor {
@Override
public void run() {
// Loop until we receive a shutdown command
while (running) {
// Loop if endpoint is paused
while (paused && running) {
...
try {
........
SocketChannel socket = null;
try {
// Accept the next incoming connection from the server
// socket
socket = serverSock.accept();
} catch (IOException ioe) {............}
...................
// setSocketOptions() will add channel to the poller
// if successful
if (running && !paused) {
if (!setSocketOptions(socket)) {
countDownConnection();
closeSocket(socket);
}
} ....
As you can see it's the setSocketOptions
method that processes a new socket
and it has the following code:
protected boolean setSocketOptions(SocketChannel socket) {
// Process the connection
try {
//disable blocking, APR style, we are gonna be polling it
socket.configureBlocking(false);
Socket sock = socket.socket();
socketProperties.setProperties(sock);
The socket
channel object associated with each connection that is used to send/receive data in the endpoints of the corresponding connection is the one that really implements a non-blocking I/O
.
Although one can always set the serverSock
object accept
method to be non-blocking, I believe that making the select
(i.e. accept) operation non-blocking would be impractical and would not server any real purpose and would not be useful in any real context. I could not think of any use case where a non-blocking accept operation would be useful. That is for me.