The proposed change is that BufferedInputStream skip should not skip
less bytes than requested unless there are no buffered bytes and a
call to skip on the wrapped input stream returns 0.
Since the return value of skip is rarely checked, a short skip will
almost certainly result in program failure.
As a consequence of this change, skip may block in situations where
it could avoid blocking by performing a short skip. Since I believe
that a short skip is likely to result in program failure, and
blocking is better than failure, I believe this is an acceptable change.
Bill
On Jul 10, 2007, at 3:35 PM, Christopher Hegarty - Sun Microsystems
wrote:
Hi Pascal, Bill, et al,
I was responsible for integrating the contributed fix for 6192696.
The problem with it was that it relied on a 'good' implementation
of the available method. By 'good' I mean that it actually returns
the amount of data that can be read without blocking, and not
simply 1. ZipInputStream.available simply returns 1 (if there is
any data available) as it is difficult to determine the amount of
available data when dynamically uncompressing a data stream.
Now, using available to try and fill as much of
BufferedInputStream's internal buffer without blocking may result
in reading only 1 byte at a time from the underlying stream,
creating a performance degradation. See
6409506 and 6411870.
I'm not sure what exactly is being proposed here, but if available
is going to be used to optimize the amount of data actually
skipped, be aware of the limitation of ZipInputStream.available and
other 'bad' available implementations.
-Chris.
Pascal S. de Kloe wrote:
Hello Martin,
6192696: BufferedInputStream.read(byte[], int, int) can block if the
entire buffer can't be filled
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192696
The problem is fill(). It doesn't check available(). The patch on
this mailing list is supposed to fix that too.
