Re: Cross-page locking mechanism for indexedDB/web storage/FileHandle ?

Yeah, I think a standalone primitive for "asynchronous atomics". The
big risk is of course that deadlocks can occur, but there's no real
way to completely avoid that while keeping a flexible platform. These
deadlocks would be asynchronous, so no thread will hang, but you can
easily end up with two pages looking "hung" to the user.

The best thing that I think we can do to help here is to enable pages
to issue a single function call which grabs multiple locks.

We could also enable registering a callback which is called when the
platform detects a deadlock. However we won't always be able to detect
deadlocks, so I'm not sure that it's a good idea.

I also don't have enough experience to know which atomics are worth
exposing, and which ones we should leave to libraries.

/ Jonas



On Wed, Jul 15, 2015 at 10:12 AM, Joshua Bell <jsbell@google.com> wrote:
> Based on similar feedback, I've been noodling on this too. Here are my
> current thoughts:
>
> https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191
>
> Feedback welcome - I was planning to send this around shortly anyway.
>
> On Wed, Jul 15, 2015 at 3:07 AM, 段垚 <duanyao@ustc.edu> wrote:
>>
>> Hi all,
>>
>> I'm developing an web-based editor which can edit HTML documents locally
>> (stored in indexedDB).
>> An issue I encountered is that there is no reliable way to ensure that at
>> most one editor instance (an instance is a web page) can open a document at
>> the same time.
>>
>> * An editor instance may create a flag entry in indexedDB or localStorage
>> for each opened document to indicate "this document is locked", and remove
>> this flag when the document is closed. However, if the editor is closed
>> forcibly, this flag won't be removed, and the document can't be opened any
>> more!
>>
>> * An editor instance may use storage event of localStorage to ask "is this
>> document has been opened by any other editor instance". If there is no
>> response for a while, it can open the document. However, storage event is
>> async so we are not sure about how long the editor has to wait before
>> opening the document.
>>
>> * IndexedDB and FileHandle do have locks, but such locks can only live for
>> a short time, so can't lock an object during the entire lifetime of an
>> editor instance.
>>
>> In a native editor application, it may use file locking
>> (https://en.wikipedia.org/wiki/File_locking) to achieve this purpose.
>> So maybe it is valuable to add similar locking mechanism to indexedDB/web
>> storage/FileHandle?
>>
>> I propose a locking API of web storage:
>>
>>   try {
>>     localStorage.lock('file1.html');
>>     myEditor.open('file1.html'); // open and edit the document
>>   } catch (e) {
>>     alert('file1.html is already opened by another editor');
>>   }
>>
>> Storage.lock() lock an entry if it has not been locked, and throw if it
>> has been locked by another page.
>> The locked entry is unlocked automatically after the page holding the lock
>> is unloaded. It can also be unlocked by calling Storage.unlock().
>>
>> What do you think?
>>
>> Regards,
>> Duan Yao
>>
>>
>>
>

Received on Thursday, 16 July 2015 00:18:40 UTC