- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 11 Jul 2012 19:11:18 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Arun Ranganathan <aranganathan@mozilla.com>, Eric U <ericu@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Kinuko Yasuda <kinuko@google.com>, Jian Li <jianli@google.com>, Alexey Proskuryakov <ap@webkit.org>, Satoru Takabayashi <satorux@google.com>, Toni Barzic <tbarzic@google.com>
On Wed, Jul 11, 2012 at 7:02 PM, Glenn Maynard <glenn@zewt.org> wrote: > On Wed, Jul 11, 2012 at 2:53 PM, Arun Ranganathan <aranganathan@mozilla.com> > wrote: >> >> I agree that making snapshotting clearer might be a good idea. >> >> It is true that reading size and lastModifiedDate are synchronous, but >> this seemed a small trade-off compared to data reads. >> >> My instinct is that an asynchronous API for mtime is overkill. > > All disk I/O needs to be asynchronous. Indeed. All APIs which generate File objects based on IO create the File objects asynchronously. This to enable the implementation to get the size and lastModification date asynchronously and then store it in the File object. For the rest of the lifetime of the File object these numbers represent a snapshot. Hence to access the loastModifiedDate doesn't require any IO. The implementation only needs to returned the saved value. / Jonas
Received on Thursday, 12 July 2012 02:12:16 UTC