- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Tue, 25 Aug 2009 11:51:54 -0700
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. > OK...I guess it makes sense to leave this as is. One thing I just realized that kind of sucks though: This makes alert based debugging much more difficult. I guess that's acceptable, though. > Given that different UAs are probably going to have other scenarios where >>>> they have to drop the lock (some of them may even be purely implementational >>>> issues), should we add some way for us to notify scripts the lock was >>>> dropped? A normal event isn't going to be of much use, since it'll fire >>>> after the scripts execution ends (so the lock would have been dropped by >>>> then anyway). A boolean doesn't seem super useful, but it's better than >>>> nothing and could help debugging. Maybe fire an exception? Are there other >>>> options? >>>> >>> >>> A generation counter might be useful. >>> >> >> Ooo, I like that idea. When would the counter increment? It'd be nice if >> it didn't increment if the page did something synchronous but no one else >> took the lock in the mean time. >> > > Defining "no-one else" may be difficult. I haven't thought this through, to > be honest, but I think you could update the counter every time the storage > mutex is released and the shared state was modified since the storage mutex > was acquired. Reading the counter would acquire the storage mutex. You'd > basically write > > var counter = window.storageMutexGenerationCounter; > ... do lots of stuff ... > if (window.storageMutexGenerationCounter != counter) { > // abort, or refresh local state, or something > } > > I'm not sure what you'd do if you discovered an undesired lock-drop, > though. If you can't write something sensible instead of "abort, or > something", it's not worth doing. > I guess it would depend on the use. Let's say a library/framework dependeds on the lock being held but does a callback (that might do something that causes the lock to be dropped). It could check the counter and raise an exception. It could also re-start "processing" if that were an acceptable answer (but by having the counter, it would only do so when necessary). I think it'll be very application specific _what_ you do when you catch such an error, but I do think it'll be valuable to developers. > 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? >> > > I thought that's what getStorageUpdates implied :-). 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. For what it's worth, I sanity checked my point with a web developer here at Google working with LocalStorage and he too thought the name was misleading/not clear. Are we the only ones?? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090825/144d7349/attachment.htm>
Received on Tuesday, 25 August 2009 11:51:54 UTC