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

[whatwg] Storage mutex

From: Jeremy Orlow <jorlow@chromium.org>
Date: Tue, 25 Aug 2009 22:36:22 -0700
Message-ID: <5dd9e5c50908252236m8e47075p767c28e11e5ad41c@mail.gmail.com>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090825/2da8e35d/attachment-0001.htm>
Received on Tuesday, 25 August 2009 22:36:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:51 UTC