Hi,
Sorry for the archaeologically late response. I'm currently documenting
FileHandle and am trying to understand how it works, so I have a couple
of questions.
I don't think this particular message received a response and I have an
unanswered interogation about it.
On Wed, Feb 29, 2012 at 1:56 AM, Glenn Maynard <gl...@zewt.org
<mailto:gl...@zewt.org?Subject=Re%3A%20Colliding%20FileWriters&In-Reply-To=%253CCA%2Bc2ei-f7fiBSZeBR0j6EpzQnUCTyyUF3bhXK86eC5Xo1_NVkw%40mail.gmail.com%253E&References=%253CCA%2Bc2ei-f7fiBSZeBR0j6EpzQnUCTyyUF3bhXK86eC5Xo1_NVkw%40mail.gmail.com%253E>>
wrote:
> On Mon, Feb 27, 2012 at 6:40 PM, Jonas Sicking <jo...@sicking.cc
<mailto:jo...@sicking.cc?Subject=Re%3A%20Colliding%20FileWriters&In-Reply-To=%253CCA%2Bc2ei-f7fiBSZeBR0j6EpzQnUCTyyUF3bhXK86eC5Xo1_NVkw%40mail.gmail.com%253E&References=%253CCA%2Bc2ei-f7fiBSZeBR0j6EpzQnUCTyyUF3bhXK86eC5Xo1_NVkw%40mail.gmail.com%253E>>
wrote:
>>
>> To do the locking without requiring calls to .close() or relying on GC
>> we use a similar setup to IndexedDB transactions. I.e. you get an
>> object which represents a locked file. As long as you use that lock to
>> read from and write to the file the lock keeps being held. However as
>> soon as you return to the event loop from the last progress
>> notification from the last read/write operation, the lock is
>> automatically released.
I LOVE THIS SO MUCH! (that's not my question, just a reaction :-) )
>> One downside of this is that it means that if you're doing a bunch of
>> separate read/write operations in separate locks, each lock is held
>> until we've had a chance to fire the final success event for the
>> operation. So if you queue up a ton of small write operations you can
>> end up mostly sitting waiting for the main thread to finish posting
>> events.
>
> It'd only slow things down if you attach an expensive, long-running event
> handler to a load/loadend event, which is an inherently bad idea if you're
> doing lots of tiny operations. Is that actually a problem?
No, that's not correct.
Most likely the implementation of this will use two threads. The main
thread which runs the JS code running in the window or worker and an
IO thread which does the file reading/writing. The main thread is also
where event handlers run. Every time a read/write is requested by the
main thread, data about this operation is sent to the IO thread
allowing the main thread to continue.
If the main thread creates two separate locks which perform two small
write operations (...)
I'd like to stop here for a minute, because I'm not entirely clear as to
what this assumptions means.
Does this part mean that during the same event loop turn, some JS code
would open 2 separate locks for the same file? If so, that sounds like
such an edge case it should just be forbidden like throwing an
ALREADY_LOCKED error when asking a second lock.
Since the first lock is released at the end of turn, the code asking the
second lock can recover by try/catching the error and deciding to lock
and play with the file in another later turn (using setTimeout( , 0) or
whatev's)
Preventing 2 locks for the same file in the same turn saves a lot of
complications it seems.
What ended up happening for Firefox implementation?
David
