AsynchronousFileChannel.open() - is it blocking?

[Vitaly Davidovich]

If the file metadata has been evicted from the page cache, then size() may
require i/o.  truncate() probably does not unless you force/fsync() the
file afterwards.  close() should also not require i/o in typical use.
 However, you can't rely on this as it's platform/OS/file system specific.

On Fri, Mar 2, 2012 at 8:46 AM, Zhong Yu <zhong.j.yu at gmail.com> wrote:

> Thanks Alan.
>
> Are you sure about size()? If a file is open, reading its size
> attribute may require IO?
>
> And what about close()? Could it also block?
>
> Zhong Yu
>
> On Fri, Mar 2, 2012 at 2:46 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
> > On 01/03/2012 22:52, Zhong Yu wrote:
> >>
> >> Is open() a potentially blocking action? Apparently so because some
> >> sanity checking (e.g. existence of the file) requires disk spin. If
> >> that's the case, it should probably be explicitly documented.
> >>
> >> And after open(), are following methods blocking or non-blocking?
> >>
> >>     size();
> >>     truncate();
> >>
> > The asynchronous operations defined by AsynchronousFileChannel are read,
> > write, and lock. The other methods, including the open method to create
> or
> > open the file, are synchronous and potentially blocking.
> >
> > -Alan.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120302/bedf040c/attachment-0001.html