- From: Michael Nordman <michaeln@google.com>
- Date: Sun, 30 Aug 2009 09:18:58 -0700
'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.htm>
Received on Sunday, 30 August 2009 09:18:58 UTC