Re: Colliding FileWriters

On Wed, Nov 28, 2012 at 4:10 PM, David Bruant <bruant.d@gmail.com> wrote:
>
> >> 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?
>

The name "lock" is a bit misleading here. It's more like the transaction in
IDB.
You can get more than one "lock" or rather "LockedFile" objects for the
same file.
Operations for these objects can be processed in parallel or serialized,
depending on the type of LockedFile objects (readonly or readwrite).
Operations for LockedFile objects which can't be processed (for example if
there's already a readwrite active LockedFile) are just queued.

Jan