W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2009

[whatwg] Storage mutex

From: Mike Shaver <mike.shaver@gmail.com>
Date: Fri, 28 Aug 2009 00:05:53 -0700
Message-ID: <cc092ba00908280005q469685fcje620e55ee9caa28e@mail.gmail.com>
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

Received on Friday, 28 August 2009 00:05:53 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:16 UTC