commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [compress] COMPRESS-491 InputStream#read returning 0
Date Mon, 02 Sep 2019 19:59:46 GMT
On Mon, Sep 2, 2019 at 11:57 AM Stefan Bodewig <bodewig@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message