On Mon, Sep 2, 2019 at 11:57 AM Stefan Bodewig <bode...@apache.org> wrote:
> Hi all > > https://issues.apache.org/jira/browse/COMPRESS-491 correctly points out > that some of our InputStream implementantions violate the contract of > the read(byte[]...) pair of methods. They may return 0 instead of trying > to block and read data. > > Digging deeper this really only seems to happen on purpose in > Deflate64CompressorInputStream and I've fixed that. > > Many of our other stream implementations wrap other streams and may > return 0 if the underlying stream does. I don't think we should be > stricter than the stream we wrap here. Do you think we should? > Without getting deep into our implementation, I'd say it is OK to surface a 0 if the underlying stream returns a 0. > > A special case is where we use SeekableByteChannel in ZipFile and > SevenZFile. The read method of ReadableByteChannel is allowed to return > 0 on read for non-blocking channels. I think seekable channels are > extremely unlikely to be non-blocking, so I'd stick with documenting the > fact. The alternative would be a busy loop (or retry with sleeps and > exponential backoff or something similar). > A busy loop sounds nasty and may end up being reported as a CPU-hogging bug. 2c, Gary > > Thoughts? > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
