On Wed, 2 Dec 2009, Jeremy Orlow wrote: > On Wed, Dec 2, 2009 at 2:06 AM, Ian Hickson <i...@hixie.ch> wrote: > > On Tue, 3 Nov 2009, Jeremy Orlow wrote: > > > > > > If we do this, we need to re-visit ways that scripts can tell > > > whether the lock has been dropped. I can't remember which idea was > > > most in favor last time we talked about it, but a counter that > > > increments every time LocalStorage is unlocked sticks out in my > > > mind. (Scripts can check the counter, do something that could cause > > > unlocking, and then verify the counter is still the same after.) > > > > The counter could be a boolean -- does the event loop have the lock > > [for the origin of the first script]. I would recommend implementing > > this as a property window.navigator.webkitStorageUpdatesLocked which > > is true when the lock is obtained and false when it is released. If > > people find it useful, we can add it to the language. > > If it's a boolean, it's possible that it was implicitly unlocked and > then re-locked. If you have a counter, you can simply check that the > count is the same as when you started.
Oh, I see. I misunderstood how the counter would work (I thought you meant it would go down again when unlocking). Yeah, that would work too. webkitStorageUpdatesLockedCount or something. > > > Another option that just came to mind is to have some flag that says > > > "throw an exception whenever there's been a serialization > > > violation". > > > > Could you elaborate on this? > > You'd have some boolean property that defaults to false (say > navigator.throwOnStorageMutexDeadlocks) that when set to true would > cause an exception to be thrown either immediately or the next time you > try to do a localStorage operation before either calling > navigator.yieldForStorageUpdates or the task ending. This would basically just be a development aid, then? I would be a bit worried about people accidentally enabling that kind of thing in production code and ending up with even more confusing user-facing bugs. It's generally been the kind of thing we've avoided standardising in the platform. It might make sense as some kind of UA-specific development aid, though. > On Wed, 25 Nov 2009, Jeremy Orlow wrote: > > > > > > I know that we've discussed approximations of run to completion > > > before, but maybe it's worth one more shot: What if on the first > > > use of document.cookie or local storage we took a snapshot of both > > > and used that during the task's execution. All writes would be > > > queued up until the task finishes, at which point they'd be written > > > to the central version of the cookie and/or local storage. This > > > would provide a consistent view of data for the duration of the task > > > and would solve almost all the atomicity problems except > > > |document.cookie = document.cookie + "foo";|. For that, I'd suggest > > > adding a method that allows scripts to do atomic modifications to > > > storage within a callback. > > > > > > I can understand everyone's desire to have completely serializable > > > semantics for local storage access and cookies (if you don't count > > > the servers' interaction with them), but maybe we need to go back to > > > use cases. In a world with WebDatabase/WebSimpleDB, I really don't > > > see anyone turning to LocalStorage except for more basic uses. > > > Most of which I'm guessing need consistent reads much more than > > > serialization of everything. > > > > > > And let's be realistic. IE has had this problem with > > > document.cookie for a long time. And IE8 now has this problem with > > > localStorage. Given that in the best case (MS and all others > > > implement the storage mutex) web developers will not be able to > > > assume localStorage and document.cookie access is atomic for many > > > years at a minimum, I think we're being pretty unrealistic about how > > > much the storage mutex is going to improve anyone's life. Let's > > > come up with an approximation, give developers a callback for atomic > > > access, and be done with it. > > > > As far as I can tell, this wouldn't remove race problems. It would in > > fact make it impossible to avoid them, since as far as I can tell you > > can't build a sane locking mechanism based on the above. > > I don't understand what you mean by building a sane locking mechanism. > > The idea is that we'd have near-run-to-completion semantics when using > local storage normally (via repeatable reads semantics on localStorage > and document.cookie) and actual run-to-completion semantics > (serializable) if you use the callback based mechanism for localStorage > access. If we decide to introduce a whole new API, then there are lots of things we could do that would make this much better, yes. I am not planning on introducing a fourth new storage API this year, though. I figure the Web needs time to get a handle on the ones we're introducing already. Without the additional API, I think it makes the storage mechanism much less reliable than no storage mutex at all. It would make it much more likely to have a race condition, since, if I'm understanding your proposal correctly, it maximises the time between the reads and the writes. > Given that network based cookie access is essentially repeatable read > semantics and both cookie and localStorage in IE and Chrome aren't even > that currently, I'd say that such semantics seem good enough. The fact > that Chrome has never gotten any complaints about the racy behavior of > its current document.cookie implementation is some evidence to support > that. I'm not convinced this is the kind of bug that would ever get reported. For localStorage, developers wouldn't see it, it would only be seen long after the fact by users who happened to once have multiple tabs open on the same page, in the form of data corruption. For cookies, it's an extremely unlikely problem to occur, given the way cookies are generally processed (infrequent access; typically either write or read only, not both; writes are typically idempotent; etc) and if it did, it's even more likely to be blamed on random things than anyone realising it's a race condition. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
