On Tue, Aug 25, 2009 at 10:28 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div class="gmail_quote">To me, getStorageUpdates seems to imply that updates have already happened and we're working with an old version of the data. I think many developers will be quite shocked that getStorageUpdates _enables_ others to update storage. In other words, 'get' seems to imply that you're consuming state that's happening anyway, not affecting behavior.<br>
</div></blockquote></div><br clear="all"></div>fetchStorageUpdates?</blockquote><div><br></div><div>fetch has the same problem. If we want to keep the "StorageUpdates" suffix, I'd go with something like allowStorageUpdates. But, no matter what, it just doesn't seem very clear that you're actively allowing another thread to use the storage mutex.</div>
<div><br></div><div>What about yieldStorageMutex? Yield is enough different from unlock that I don't think it'll leave developers looking for the lock function. Yield fits pretty well since this is essentially cooperative multi-tasking. StorageMutex is good because that's what its actually affecting.</div>
</div>