AsynchronousFileChannel.open() - is it blocking? (original) (raw)

Vitaly Davidovich vitalyd at gmail.com
Fri Mar 2 05:55:24 PST 2012

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

More information about the nio-dev mailing list