- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Fri, 28 Aug 2009 12:36:41 -0700
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