Neil Richards said the following on 04/09/11 10:04:
You are correct that the ZipFileInflaterInputStream code is not
inherently thread-safe (without user synchronization), but then, the
contract of InputStream does not require it to be (as Sherman previously
observed on this thread).
The previous suggested fix caused ZFIIS to interact with the finalize
thread, thus it had to care about being thread-safe at least to the
extent of safe-guarding that interaction.
As Sherman observed, and I agreed, finalization on that object is not
really needed, so the inherent cross-thread interaction that would be
introduced by the finalize method can be avoided in that case, and so
the need to cater for inherent thread-safety can likewise be avoided.
Ok.
David
------
With the latest suggested change, if the ZFIIS is driven by multiple
threads, it will be done at the user's (developer's) behest, so the user
can (should) know to implement suitable synchronization to ensure
correct behaviour.
Therefore, I believe the same lack of synchronization in ZFIIS as there
was in the previous anonymous inner class to be entirely justified in
this case, given that it no longer has a finalize() method.
Please let me know if you still disagree with this assessment,
Thanks,
Neil
(Sent from my phone, so probably missing my usual signature)
