On 2016-11-01, M N wrote:
>> read never indicates EOF as it stands, I think we should return -1
>> rather than 0 when position equals size. WDYT?
> Yes, indeed the contract specifies to return -1 in this case so we
> should change this.
will do.
>>> In resize() method there is also a danger to
Hi Stefan,
(...)
> read never indicates EOF as it stands, I think we should return -1
> rather than 0 when position equals size. WDYT?
Yes, indeed the contract specifies to return -1 in this case so we should
change this.
>> In resize() method there is also a danger to overflow integer
Hi Maciej
patch applied.
On 2016-10-22, M N wrote:
> Going back to the fix - first I've done the homework and read the contract of
> SeekableByteChannel.position(long) method.
> It influences read() and write() operation.
> Citation of the most important part:
> "Setting the position to a
... and patch is attached to Jira COMPRESS-327
From: M N
Sent: Saturday, October 22, 2016 2:04:53 PM
To: dev@commons.apache.org
Subject: Re: [compress] Added in-memory support for zip and 7z
All,
OK, volatile won't hurt anyway.
Going
All,
OK, volatile won't hurt anyway.
Going back to the fix - first I've done the homework and read the contract of
SeekableByteChannel.position(long) method.
It influences read() and write() operation.
Citation of the most important part:
"Setting the position to a value that is greater
On 2016-10-20, wrote:
> Even when a stream is not thread safe I try at least to make close()
> safe/atomic as aborts and finalizers or shutdown hooks are natural
> sources for concurrency – all using close().
true.
> (However I guess it is less problematic for memory
On 2016-10-20, M N wrote:
> I have created tests for SeekableInMemoryByteChannel and spot small error.
Great, thanks Maciej.
> Attached is a patch with tests and proposed fix.
The mailing list is set up to strip attachments (at least I don't see
any). Could you attach it to a JIRA issue?
Hello,
Even when a stream is not thread safe I try at least to make close()
safe/atomic as aborts and finalizers or shutdown hooks are natural sources for
concurrency – all using close().
Using a AtomicBoolean or flag is good for that.
(However I guess it is less problematic for memory
Hi Stefan,
I have created tests for SeekableInMemoryByteChannel and spot small error.
Attached is a patch with tests and proposed fix.
Regarding thread safety I think would be more clear to remove volatile and
document a class as not thread safe.
I think the need for thread safe
Hi all
actually it is SeekableByteChannel-support combined with a byte[] backed
implementation of SeekableByteChannel.
Over the past few days I've rewritten the zip and 7z packages to become
independent of RandomAccessFile and thus no longer require writing to or
reading from a file. The
10 matches
Mail list logo