On 09/04/14 22:16, Alan Bateman wrote:
On 09/04/2014 20:10, Seán Coffey wrote:
I played around with adding some skip testing Alan but didn't see it
increase the rate of failure on an unpatched binary. Since
ZipFileInputStream.read(..) is the trouble method and now has better
synchronized access to reading and updating rem, I believe we're
good. skip(long) can trigger a close() but close() can't free up the
resources without the ZipFile.this lock. As mentioned, having
multiples threads reading from the one zip stream would make no sense
anyhow.
Let me know if I need to make changes. I don't think we want to add
extra sync costs to the class.
If you are only going to synchronize read then you will need to take a
copy of rem and pos, otherwise you have to assume that the check and
limiting of len isn't reliable, same thing for pos which could be way
out of range due to concurrent usages of skip.
Let me catch up with you in the morning on this Alan. In the interest
of keeping the code optimal, I think we can skip these checks. The
native ZIP_Read function runs a range check on the len and pos values
passed in.
regards,
Sean.
-Alan.
