Patch to fix BufferedInputStream.skip and bug 4254082
Pascal S. de Kloe
pascal at quies.net
Thu Jul 12 07:43:11 PDT 2007
This may cause dead-locks. Do you really want such a bug because some
people may not have gotten the API right?
On Wednesday 11 July 2007 00:50:22 you wrote:
> 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
> On Jul 10, 2007, at 3:35 PM, Christopher Hegarty - Sun Microsystems
> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20070712/902109a2/attachment.bin
More information about the core-libs-dev