- From: Mike Shaver <mike.shaver@gmail.com>
- Date: Fri, 28 Aug 2009 00:05:53 -0700
On Tue, Aug 25, 2009 at 10:36 PM, Jeremy Orlow<jorlow at chromium.org> wrote: > On Tue, Aug 25, 2009 at 10:28 PM, Robert O'Callahan <robert at ocallahan.org> > wrote: >> >> On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow <jorlow at chromium.org> >> wrote: >>> >>> 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. >> >> fetchStorageUpdates? > > 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. > 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. processPendingStorageUpdates? processStorageUpdates? FWIW I would expect getStorageUpdates to return some storage updates to the caller, like a getter. I would expect fetchStorageUpdates to do the same thing, except maybe involving something over the network, and I would be a little puzzled about why it wasn't just getStorageUpdates. Mike
Received on Friday, 28 August 2009 00:05:53 UTC