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

Re: Colliding FileWriters

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 23 Jan 2012 10:30:39 -0500
Message-ID: <CABirCh86bru_1GWzkCaotpbXkH01yufjiUHtCP8Cpu4ab713Fw@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Eric U <ericu@google.com>, Webapps WG <public-webapps@w3.org>, Jian Li <jianli@chromium.org>
On Mon, Jan 23, 2012 at 4:02 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> Yes. How exactly it works is something that is being discussed in this
> very thread. The idea discussed so far is to have an explicit
> FileWriter.close() call which would release the lock. The lock would
> also be released when the FileWriter is GCed.
>

That'd expose GC behavior, though.  Having a function called that locks
during the call and unlocks when it returns would be fine, but wouldn't
work with the async API at all.

If the lock was associated with the Entry, then the GC exposure would be
reduced, but not eliminated.  You would lose the lock at the same time you
lost the Entry itself, so the thread that grabbed the lock wouldn't see GC
behavior (barring multiple Entries for the same file).  However, any other
threads waiting on that lock would still see the GC if they're waiting on
the lock.

I suppose the lock could be retained until you return to the event loop
without any reads or writes in progress on the FileWriter, but that's a
little magic and easy to get wrong (eg. a setTimeout in the async call
chain would cause you to lose the lock).

That wouldn't make much sense since FileWriter is tied to a specific
> file, whereas the functions on FileReader is passed the file to read
> as an argument.
>

I hadn't noticed that.  That's an unfortunate inconsistency...

-- 
Glenn Maynard
Received on Monday, 23 January 2012 15:31:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT