Alan.Bateman at Sun.COM
Mon Oct 19 13:00:31 PDT 2009
Joel Uckelman wrote:
> I don't follow. What is the problem with asynchronously closing streams
> that you're referring to? Is it just that not all streams are thread safe?
> I'm a bit hazy on whether locking belongs in an FS implementation at all
> (given the current design). E.g, the default FS doesn't provide any way of
> locking itself, though it happens that you can lock files by getting
> FileLocks from the FileChannels returned by the default FS. For zipfs, the
> Channels aren't FileChannels, so you can't lock ZIP entries.
> On the other hand, if zipfs doesn't provide any kind of locking mechanism,
> then it's going to be hard to use it in a multithreaded app. Maybe what
> I'm moving toward is that Path should have methods for acquiring read and
> write locks.
On one level you'll need to coordinate the re-writing of the zip file
with other VMs or entities that are accessing that zip file. For
example, our zip implementation mmaps the central directory on some
platforms so if one VM re-writes the zip file then it's very possible
that it will cause access in other VMs to SIGBUS. File locking (via
FileChannel.lock) might help but I suspect you'll need more - perhaps
even a shared server to coordinates access.
Within a VM, the provider could coordinate access where you have several
FileSystem instances representing different file systems on the same zip
file. For zip entries, the simplest starting point is that write access
requires exclusive access. Later you could define provider specific
OpenOptions to support other locking modes.
As regards asynchronous close - always tricky. My point was that
asynchronous close of streams it not well defined. Without checking, I
can't say how robust the zip streams are when closed asynchronously but
you'll likely have bigger fish to fly before you come to this.
More information about the nio-dev