<div>'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. </div>
<div><br></div><div>Back to a comment long ago in this thread...</div><div><br></div><div>> <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Authors would be confused that there's no aquireLock() API.</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><span class="Apple-style-span" style="font-size: 13px; "></span><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">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. </span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">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.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font><br><div class="gmail_quote">On Sat, Aug 29, 2009 at 6:10 PM, Mike Shaver <span dir="ltr"><<a href="mailto:mike.shaver@gmail.com">mike.shaver@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Aug 28, 2009 at 3:36 PM, Jeremy Orlow<<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
> Can a plugin ever call into a script while a script is running besides when<br>
> the script is making a synchronous call to the plugin? If so, that worries<br>
> me since it'd be a way for the script to lose its lock at _any_ time.<br>
<br>
</div>Does the Chromium out-of-process plugin model take steps to prevent<br>
it? I had understood that it let such things race freely, but maybe<br>
that was just at the NPAPI level and there's some other interlocking<br>
protocol before script can be invoked.<br>
<font color="#888888"><br>
Mike<br>
</font></blockquote></div><br></div>