- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 15 Jul 2015 17:17:42 -0700
- To: Joshua Bell <jsbell@google.com>
- Cc: 段垚 <duanyao@ustc.edu>, "public-webapps@w3.org" <public-webapps@w3.org>
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