# Non Blocking with Traditional Java IO - On the Use of InputStream.available() and Thread.sleep()

Some time ago I did quite a lot of IO in Java and I yet did not see this way of reading a InputStream from a Socket:

     InputStream in=channel.getInputStream();    channel.connect();    byte[] tmp=new byte[1024];    while(true){      while(in.available()>0){        int i=in.read(tmp, 0, 1024);        if(i<0)break;        System.out.print(new String(tmp, 0, i));      }      if(channel.isClosed()){        System.out.println("exit-status: "+channel.getExitStatus());        break;      }      try{Thread.sleep(1000);}catch(Exception ee){}    }    channel.disconnect();

This comes from a piece of code from an example of JSch , a good ssh client in java. A work collegue had the bad idea to remove the Thread.sleep call and was struggling with why it would randomly work.The way I would have done it is the following:
     InputStream in=channel.getInputStream();    channel.connect();    byte[] tmp=new byte[1024];    int bytesRead = 0;    while((bytesRead = in.read(tmp,0,1024) >= 0){      System.out.print(new String(tmp, 0, bytesRead));    }    if(channel.isClosed()){      System.out.println("exit-status: "+channel.getExitStatus());      break;    }    channel.disconnect();

This has the advantage of being more readable and having less secret spices in it. In the first code, the call to available() is non blocking, meaning that without the Thread.sleep(), there will never be the time for the socket buffer to fill up. But is the first code more efficient or the second code?

I did a search on google to understand the interest of the first code. The only advantages I found in the first code are the possibility to interrupt the thread running the code and a finer grained control on timeouts.

There is a lengthy explanation by Doug Lea in his book “Concurrent Programming in Java”. This book usually provides excellent explanations, and is a must read for anybody doing concurrent programming. But this time, about this subject, I did not find him that clear.

There is a more simple explanation in a course from San Diego State University (see last example)
A read() on an inputstream or reader blocks. Once a thread calls read() it will not respond to interrupt() (or much else) until the read is completed. This is a problem when a read could take a long time: reading from a socket or the keyboard. If the input is not forth coming, the read() could block forever.