Hello Bill, 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 > 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.
signature.asc
Description: This is a digitally signed message part.
