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 than the current size is legal but does not change the size of the entity. A later attempt to read bytes at such a position will immediately return an end-of-file indication. A later attempt to write bytes at such a position will cause the entity to grow to accommodate the new bytes; the values of any bytes between the previous end-of-file and the newly-written bytes are unspecified." My changes to SeekableInMemoryByteChannel: 1. In read() method added check whether position exceeds size. 2. Added check for negative argument in position(long). 3. Added check for open channel in position(long) to fail immediately. In general the contract specifies to throw ClosedChannelExceptionexception by each method. In resize() method there is also a danger to overflow integer when we are close to Integer.MAX_VALUE - either sum pos + wanted or shift may cause this. Let me know your thougths. Cheers, Maciej ________________________________ From: Stefan Bodewig <bode...@apache.org> Sent: Friday, October 21, 2016 4:19:11 AM To: dev@commons.apache.org Subject: Re: [compress] Added in-memory support for zip and 7z On 2016-10-20, <e...@zusammenkunft.net> 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 resources) In the case of SeekableInMemoryByteChannel close really only has effects on read/write operations, so it may not be that important in this case. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
