[whatwg] Storage mutex

On Fri, Aug 28, 2009 at 4:05 AM, Kevin Benson <kevin.m.benson at gmail.com>wrote:

> 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.


Both commit and allow seem like good alternatives.  I still like
yieldStorageMutex, but I understand using the word Mutex might seem too
scary.  Now I'll just pray that Ian also finds one of these names to be
better than getStorageUpdates.  :-)


On Sun, Aug 23, 2009 at 11:33 PM, Robert O'Callahan <robert at ocallahan.org>
 wrote:

> On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow <jorlow at chromium.org>
>  wrote:
>
>> On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan <robert at ocallahan.org>
>>  wrote:
>>
>>> On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow <jorlow at chromium.org>
>>>  wrote:
>>>
>>>> First of all, I was wondering why all user prompts are specified as
>>>> "must release the storage mutex" (
>>>> http://dev.w3.org/html5/spec/Overview.html#user-prompts).  Should this
>>>> really say "must" instead of "may"?  IIRC (I couldn't find the original
>>>> thread, unfortunately) this was added because of deadlock concerns.  It
>>>> seems like there might be some UA implementation specific ways this could
>>>> deadlock and there is the question of whether we'd want an alert() while
>>>> holding the lock to block other execution requiring the lock, but I don't
>>>> see why the language should be "must".  For Chromium, I don't think we'll
>>>> need to release the lock for any of these, unless there's some
>>>> deadlock scenario I'm missing here.
>>>
>>>
>>> So if one page grabs the lock and then does an alert(), and another page
>>> in the same domain tries to get the lock, you're going to let the latter
>>> page hang until the user dismisses the alert in the first page?
>>>
>>
>> Yes.  And I agree this is sub-optimal, but shouldn't it be left up to the
>> UAs what to do?  I feel like this is somewhat of an odd case to begin with
>> since alerts lock up most (all?) browsers to a varying degrees even without
>> using localStorage.
>>
>
> That behaviour sounds worse than what Firefox currently does, where an
> alert disables input to all tabs in the window (which is already pretty
> bad), because it willl make applications in visually unrelated tabs and
> windows hang.
>

Apparently (based on the reply from Jonas on the thread I split this into)
it sounds like this behavior is actually a bug.  Either way, it breaks
run-to-completion and (as far as I can tell) goes against the spec (but I'm
fuzzy on this part).

So I guess the question is why we should make a special case for
LocalStorage regarding modal dialog boxes?


On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow <jorlow at chromium.org> wrote:

> On Tue, Aug 18, 2009 at 4:26 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
>> It's also worth noting that Chromium is probably going to need to drop the
>> storage mutex for most if not all plugin related calls due to deadlock
>> conditions.  If there were some place to mention this as a "may" type thing,
>> it'd be good, but I realize it's probably out of scope for HTML 5.
>>
>
> Oops.  The spec already does specify this behavior:
> http://dev.w3.org/html5/spec/Overview.html#storage-mutex
>

One question about this, actually.  I'm a bit troubled by the following
language:

"Whenever a script<http://dev.w3.org/html5/spec/Overview.html#concept-script>
calls
into a plugin <http://dev.w3.org/html5/spec/Overview.html#plugin>, and
whenever a plugin <http://dev.w3.org/html5/spec/Overview.html#plugin> calls
into a script <http://dev.w3.org/html5/spec/Overview.html#concept-script>,
the user agent must release the storage
mutex<http://dev.w3.org/html5/spec/Overview.html#storage-mutex>
."

Can a plugin ever call into a script while a script is running besides when
the script is making a synchronous call to the plugin?  If so, that worries
me since it'd be a way for the script to lose its lock at _any_ time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090828/8a60d27f/attachment-0001.htm>

Received on Friday, 28 August 2009 12:36:41 UTC