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

[whatwg] Storage mutex

From: Kevin Benson <kevin.m.benson@gmail.com>
Date: Fri, 28 Aug 2009 07:05:43 -0400
Message-ID: <7c7658460908280405m6734a3d2pda094e9897477982@mail.gmail.com>
On Sun, Aug 23, 2009 at 1:22 AM, Jeremy Orlow<jorlow at chromium.org> wrote:
> On Tue, Aug 18, 2009 at 4:26 PM, Jeremy Orlow?<jorlow at chromium.org>?wrote:
>>
>>> Lastly, is navigator.getStorageUpdates() the right name for the function
>>> that drops the lock? ?Why was it changed from navigator.releaseLock()? ?I
>>> assume we're trying to avoid the word "lock", but the reason why you'd need
>>> to call a function to get updates is not clear without understanding the
>>> concept of a lock...so what's the point of making this so cryptic?
>>
>> Authors would be confused that there's no aquireLock() API.
>
> Good point.
> But getStorageUpdates is still not the right name for it. ?The only way that
> there'd be any updates to get is if, when you call the function, someone
> else takes the lock and makes some updates. ?Maybe it should be yieldStorage
> (or yieldStorageMutex)? ?In other words, maybe the name should imply that
> you're allowing concurrent updates to happen?

How about:

commitStorageUpdates

... since a new transactor cannot write to storage until a commit
point is reached by the current transactor finishing up and releasing
the lock.

-- 
-- 
   --
       --
       ????
    K e V i N
   /?????????\
Received on Friday, 28 August 2009 04:05:43 UTC

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