W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Colliding FileWriters

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 10 Jan 2012 13:08:48 -0800
Message-ID: <CA+c2ei97hm1gxZn=U4Q_69MeV4mHZ-Db198YMdmu9h+d6=Ui+A@mail.gmail.com>
To: Eric Uhrhane <ericu@google.com>, Webapps WG <public-webapps@w3.org>
Hi All,

We've been looking at implementing FileWriter and had a couple of questions.

First of all, what happens if multiple pages create a FileWriter for
the same FileEntry at the same time? Will both be able to write to the
file at the same time and whoever writes lasts to a given byte wins?
This is different from how file systems normally work since as long as
file is open for writing that tends to prevent other processes from
opening the same file.

A second question is why is FileEntry.createWriter asynchronous? It
doesn't actually do any IO and so it seems like it could return an
answer synchronously.

Is the intended way for this to work that FileEntry.createWriter acts
as a choke point and ensures that only one active FileWriter for a
given FileEntry exists at the same time. I.e. if one page creates a
FileWriter for a FileEntry and starts writing to it, any other caller
to FileEntry.createWriter will wait to fire it's callback until the
first caller was done with its FileWriter. If that is the intended
design I would have expected FileWriter to have an explicit .close()
function though. Having to wait for GC to free a lock is always a bad

Would this also explain why FileEntry.getFile is asynchronous? I.e. it
won't call it's callback until all current FileWriters have been

These questions both apply to what's the intended behavior spec-wise,
as well as what does Google Chrome do in the current implementation.

/ Jonas
Received on Tuesday, 10 January 2012 21:09:46 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC