[whatwg] Storage mutex

[Michael Nordman]

'Commit' implies that it hasn't been committed yet, which is not true. This
will be misleading to those developers that do understand the locking
semantics (and transactional semantics) and are looking to defeat them. With
the 'commit' naming, we'd be doing a diservice to exactly the sort of
developers this API is intended for, all to avoid exposing the fact that
locks actually are involved to the more casual developer.

Back to a comment long ago in this thread...

> Authors would be confused that there's no aquireLock() API.

Regardless of what you call it, authors are going to be confused by this
API. This is because the locking semantics are otherwise hidden, the lock
acquisition is implicit. This API provides an explicit means of unlocking.
No matter how you slice it... thats what's going on.

Without an understanding of the locking semantics, its going to be
confusing. Hiding those semantics is the source of the confusion to start
with. Not naming this this releaseStorageLock only adds to the confusion.



On Sat, Aug 29, 2009 at 6:10 PM, Mike Shaver <mike.shaver at gmail.com> wrote:

> On Fri, Aug 28, 2009 at 3:36 PM, Jeremy Orlow<jorlow at chromium.org> wrote:
> > Can a plugin ever call into a script while a script is running besides
> when
> > the script is making a synchronous call to the plugin?  If so, that
> worries
> > me since it'd be a way for the script to lose its lock at _any_ time.
>
> Does the Chromium out-of-process plugin model take steps to prevent
> it?  I had understood that it let such things race freely, but maybe
> that was just at the NPAPI level and there's some other interlocking
> protocol before script can be invoked.
>
> Mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090830/f888f19d/attachment-0002.htm>