[whatwg] Storage mutex
Jeremy Orlow
jorlow at chromium.org
Fri Aug 28 12:36:41 PDT 2009
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>
More information about the whatwg
mailing list