Question

I am trying to write a piece of unblocking code to read from a PipedInputStream. It basically checks if there is anything to be read before calling the blocking read API:

int n = 0;
if ((n = pipedInputStream_.available()) > 0) {
     pipedInputStream_.read(...)
}

Reading through the java API doc I cant tell for sure what that check should be, since the possible values are zero (implies no data, or closed/broken stream) or greater than zero . So how can the caller know if there is anything to be read at all?

“Returns the number of bytes that can be read from this input stream without blocking, or 0 if this input stream has been closed by invoking its close() method, or if the pipe is unconnected, or broken.”

Looking at the source it seems like the only values are zero or greater than zero.

public synchronized int available() throws IOException {
    if(in < 0)
        return 0;
    else if(in == out)
        return buffer.length;
    else if (in > out)
        return in - out;
    else
        return in + buffer.length - out;
}

Answer 1

If available() returns zero, there are no bytes available to read at present. Per the documentation you quote, that can be so for several reasons:

• The pipe was closed.
• The pipe is broken.
• All the previously-available input (if any) was already consumed.

A zero return value from available() might imply that an error had occurred, implying that you will never be able to read any more data through the pipe in the future, but you can’t tell for sure here, because zero might be indicating that third condition above, where blocking on InputStream#read() might eventually yield more data that the corresponding OutputStream side will push through the pipe.

I don’t see that it’s possible to poll a PipedInputStream with available() until more data becomes available, because you’ll never be able to distinguish the terminal cases above (the first and the second) from the reader being more hungry than the writer. Like so many stream interfaces, here too you have to try to consume and be ready to fail. That’s the trap; InputStream#read() will block, but not until you commit to blocking on an attempt to read will you be able to discern that no more input is coming.

It is not feasible to base your consuming actions on available(). If it returns a positive number, there’s something to be read, but of course even what is available now might not be “enough” to satisfy your consumer. You will find your application easier to manage if you commit a thread to consuming the InputStream in blocking fashion and skip the polling with available(). Let InputStream#read() be your sole oracle here.