Re: Colliding FileWriters

On Tue, Jan 10, 2012 at 1:08 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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 isn't currently specified, and that's a hole we should fill.  By
not having it in the spec, my assumption would be that last-wins would
hold, but it would be good to clarify it if that's the behavior we
want.  It's especially important given that there's nothing like
fflush(), which would help users know what "last" meant.  Speaking of
which, should we add a flushing mechanism?

> 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.

You're perhaps thinking of windows, where by default files are opened
in exclusive mode?  On other operating systems, and on windows when
you specify FILE_SHARE_WRITE in dwShareMode in CreateFile, multiple
writers can exist simultaneously.

> 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.

FileWriter has a synchronous length property, just as Blob does, so it
needs to do IO at creation time to look it up.

> 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
> idea.

Agreed re: GC, but currently in Chromium there is no choke point, and
one can create multiple writers, which can stomp on each others'
writes if that's what the user requests.  That being said, we don't
really hold files open right now, except during a write call.  In
between writes, we close the file, so while collisions are possible,
more likely one write will win entirely.  But we are opening the files
in shared mode.

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

Nope.  It's asynchronous because a File is a Blob, and has a
synchronous length accessor, so we look up the length when we mint the
File.  Note that the length can go stale if you have multiple writers,
as we want to keep it fast.

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

I'm personally OK with the current Chrome implementation, which does
no locking.  If users want transactional behavior, there are better
ways to get that via databases.  But I'm open to discussion.

Received on Wednesday, 11 January 2012 00:08:53 UTC