Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Thu, Sep 3, 2009 at 6:59 PM, Jeremy Orlow wrote: > On Fri, Sep 4, 2009 at 10:48 AM, Michael Nordman wrote: > >> > Shared worker access would be a plus. >> Indeed. The lack of access to LocalStorage in 'workers' forces developers >> to use the more difficult database api for all storage needs, and to roll >> their own change event mechanisms (based on postMessage). Thats a bunch of >> busy work if a name/value pair schema is all your app really needs. >> > > For the record, all the developers I've talked to about the current state > of AppCache+storage+workers have been VERY disheartened. IE and Firefox > have no intentions of supporting WebDatabase any time soon. localStorage is > not available from workers. AppCache requires apps to be 100% client based > (the server needs to server static pages and the logic must be in JS) if you > have any personalization/authentication. Workers are only accessible via > message passing. Sure, we can imagine ways that nearly every application > _can_ be written in such environments, but in many cases these designs are > quite different from what web developers are used to. > > I think there are good reasons for all the design decisions we're making, > but I'm worried we're not looking at the big picture enough. > Thats a great summary of the short comings in these 'storage' related things, and I share your concerns (no surprise i'm sure).
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Fri, Sep 4, 2009 at 10:59 AM, Jeremy Orlow wrote: > On Fri, Sep 4, 2009 at 10:48 AM, Michael Nordman wrote: > >> > Shared worker access would be a plus. >> Indeed. The lack of access to LocalStorage in 'workers' forces developers >> to use the more difficult database api for all storage needs, and to roll >> their own change event mechanisms (based on postMessage). Thats a bunch of >> busy work if a name/value pair schema is all your app really needs. >> > > For the record, all the developers I've talked to about the current state > of AppCache+storage+workers have been VERY disheartened. IE and Firefox > have no intentions of supporting WebDatabase any time soon. localStorage is > not available from workers. AppCache requires apps to be 100% client based > (the server needs to server static pages and the logic must be in JS) if you > have any personalization/authentication. Workers are only accessible via > message passing. Sure, we can imagine ways that nearly every application > _can_ be written in such environments, but in many cases these designs are > quite different from what web developers are used to. > > I think there are good reasons for all the design decisions we're making, > but I'm worried we're not looking at the big picture enough. > On a related note, it might even be possible that saving developers from explicitly having to think about _any_ concurrency is actually hurting them more than it's helping. And I'm not just talking about the short term, here.
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Fri, Sep 4, 2009 at 10:48 AM, Michael Nordman wrote: > > Shared worker access would be a plus. > Indeed. The lack of access to LocalStorage in 'workers' forces developers > to use the more difficult database api for all storage needs, and to roll > their own change event mechanisms (based on postMessage). Thats a bunch of > busy work if a name/value pair schema is all your app really needs. > For the record, all the developers I've talked to about the current state of AppCache+storage+workers have been VERY disheartened. IE and Firefox have no intentions of supporting WebDatabase any time soon. localStorage is not available from workers. AppCache requires apps to be 100% client based (the server needs to server static pages and the logic must be in JS) if you have any personalization/authentication. Workers are only accessible via message passing. Sure, we can imagine ways that nearly every application _can_ be written in such environments, but in many cases these designs are quite different from what web developers are used to. I think there are good reasons for all the design decisions we're making, but I'm worried we're not looking at the big picture enough.
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
> Shared worker access would be a plus. Indeed. The lack of access to LocalStorage in 'workers' forces developers to use the more difficult database api for all storage needs, and to roll their own change event mechanisms (based on postMessage). Thats a bunch of busy work if a name/value pair schema is all your app really needs. How hard can it be to find a way to allow LocalStorage access to workers :) On Thu, Sep 3, 2009 at 6:32 PM, Jeremy Orlow wrote: > On Fri, Sep 4, 2009 at 10:25 AM, Drew Wilson wrote: > >> To be clear, I'm not trying to reopen the topic of giving cookie access to >> workers - I'm happy to restrict cookie access to document context (I >> probably shouldn't have brought it up again). > > > And to be clear: I don't have strong opinions about cookies > being accessible in Workers, but I do think localStorage needs to > be accessible. That said, my primary goal here is to make the storage mutex > more reasonable (i.e. something vendors will actually implement). Shared > worker access would be a plus, though. >
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Fri, Sep 4, 2009 at 10:25 AM, Drew Wilson wrote: > To be clear, I'm not trying to reopen the topic of giving cookie access to > workers - I'm happy to restrict cookie access to document context (I > probably shouldn't have brought it up again). And to be clear: I don't have strong opinions about cookies being accessible in Workers, but I do think localStorage needs to be accessible. That said, my primary goal here is to make the storage mutex more reasonable (i.e. something vendors will actually implement). Shared worker access would be a plus, though.
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
To be clear, I'm not trying to reopen the topic of giving cookie access to workers - I'm happy to restrict cookie access to document context (I probably shouldn't have brought it up again). I do agree with Jeremy that we should rethink the spec language around cookie consistency to reflect what implementors are actually willing to build. -atw On Thu, Sep 3, 2009 at 6:17 PM, Jeremy Orlow wrote: > On Fri, Sep 4, 2009 at 8:17 AM, Benjamin Smedberg > wrote: > >> What kind of conflict? There is no need to "merge" individual cookies: >> whichever one was set (or removed) last wins. > > > I think this strategy would work fine for cookies since the HTTP side of > them is inherently racy. I think such behavior would be pretty > counter-intuitive for localStorage, though. > > If we did go with this strategy, I think we could give access to shared > workers, and someone could use those if they needed better "atomicity". >
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Fri, Sep 4, 2009 at 8:17 AM, Benjamin Smedberg wrote: > What kind of conflict? There is no need to "merge" individual cookies: > whichever one was set (or removed) last wins. I think this strategy would work fine for cookies since the HTTP side of them is inherently racy. I think such behavior would be pretty counter-intuitive for localStorage, though. If we did go with this strategy, I think we could give access to shared workers, and someone could use those if they needed better "atomicity".
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/3/09 5:06 PM, Aryeh Gregor wrote: > On Thu, Sep 3, 2009 at 4:25 PM, Benjamin Smedberg > wrote: >> * When the script sets document.cookie, it calculates the delta with the >> original data and "commit" the changes. > > What if there's a conflict with other changes that happened in the meantime? What kind of conflict? There is no need to "merge" individual cookies: whichever one was set (or removed) last wins. - --BDS -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKoE5vSSwGp5sTYNkRAhNzAKCb8bvv51i0es73UI8zLgJ+j7d/IwCg1e2K XYAcugpbUpEqLRgz8SONvxI= =uf1l -END PGP SIGNATURE-
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Thu, Sep 3, 2009 at 1:32 PM, Benjamin Smedberg wrote: > On 9/3/09 4:24 PM, Drew Wilson wrote: > > I think the canonical racy case is "the page wants to keep a counter for > > the number of times event X occurs" in a cookie or local storage. > > > > It doesn't seem to be possible to achieve this without the mutex - the > > proposal below would break down if two pages tried to increment the > > cookie value simultaneously (if both pages changed "cookieValue=3" to > > "cookieValue=4" at the same time, the result of your merge step would > > likely be "cookieValue=4", not "cookieValue=5" as one might intend). > > Is that case important? I think that it's more important to make sure that > script doesn't inadvertently remove or modify cookies due to races in > document.cookie, but that maintaining a single-threaded view of the cookie > data is not desirable. > You're asking the wrong guy - I'm in the "don't bother trying to ensure consistency" camp :) I'm just parroting the arguments that were offered previously. If I hadn't lost the arguments about providing workers access to cookies, then I'd say that pages that care about cookie consistency should set cookies via a SharedWorker. But failing that, it seems like the choices are fairly stark: ensure consistency and take the performance hit in all multi-threaded browsers, or explicitly disavow consistency, and console ourselves by making our future APIs more multi-process friendly. I do understand the point of view of the "correctness over performance" camp - however, as Jeremy points out, it doesn't sound like those arguments have gotten much traction with actual implementors yet. > > --BDS >
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Thu, Sep 3, 2009 at 4:25 PM, Benjamin Smedberg wrote: > * When the script sets document.cookie, it calculates the delta with the > original data and "commit" the changes. What if there's a conflict with other changes that happened in the meantime?
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/3/09 4:24 PM, Drew Wilson wrote: > I think the canonical racy case is "the page wants to keep a counter for > the number of times event X occurs" in a cookie or local storage. Is it important that continue to work without racing? I don't think it's especially important: it's similar to how HTTP responses may race. The only thing I'm particularly concerned about is data consistency so that setting document.cookie does not inadvertently undo changes which happened while the script was executing. - --BDS -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKoCqPSSwGp5sTYNkRAm7YAJ9TtPVdK8j6sOwRD6ZA+qn45sU0BACfSPlZ vZMlhKARLnu9PU57C3xjrP4= =0kXs -END PGP SIGNATURE-
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/1/09 7:31 PM, Jeremy Orlow wrote:
> Does the silence mean that no one has any intention of implementing
> this? If so, maybe we should resign ourselves to a break in the single
> threaded illusion for cookies. This doesn't seem too outlandish
> considering that web servers working with cookies will never have such a
> guarantee and given that we have no evidence of widespread breakage with
> IE 8 and Chrome.
We (Firefox) just started looking at this seriously: the performance
implications of the current global mutex are pretty unpleasant. Reading the
spec, I didn't realize that the mutex was global instead of per-domain; I
only figured that out reading the discussions here.
The major race condition appears to be code on the web that gets
document.cookie, parses and modifies the string it to add or remove a
particular cookie, and sets document.cookie again. This pattern could race
against HTTP requests which also set cookies.
Chris Jones proposed that we behave in a script-consistent manner without
actually implementing any sort of mutex:
* When a script gets document.cookie, "check out" a consistent view of the
cookie data. While the script runs to completion, its view of
document.cookie does not change.
* When the script sets document.cookie, it calculates the delta with the
original data and "commit" the changes.
* The consistent view is maintained until the script runs to completion (or
enters a nested event loop, all the locations which are currently marked as
releasing the storage Mutex in the current spec)
* HTTP Set-Cookie headers stomp on prior data at any time, but don't
interfere with the consistent script view above.
It would be nice to provide a web API to perform the operation of setting a
cookie atomically, just as the Set-Cookie HTTP header does. That is:
document.setCookie('foo=bar; domain=subd.example.com')
It's not clear whether/how this same algorithm could be applied to
localStorage, since the amount of data required to create a consistent state
is potentially much larger. Is there an inherently racy API in .localStorage
which we need to protect with complicated mutex/transactional schemes?
In addition, we had concerns about how the web-browser UI itself might
interact with the global mutex. I don't think we'd want browser UI such as
the cookie manager or "Clear Private Data" to wait for content script to run
to completion. Can we make it explicit in the spec that the UA may remove
cookies or localStorage data at any time without owning the storage mutex?
- --BDS
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFKoCYdSSwGp5sTYNkRAi9yAKCq3GesFDNDrn134621Hm8XJaMB8ACgmIhC
3VcXlEKmSb2l83ekH0j3Hgg=
=FldI
-END PGP SIGNATURE-
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
I think the canonical racy case is "the page wants to keep a counter for the
number of times event X occurs" in a cookie or local storage.
It doesn't seem to be possible to achieve this without the mutex - the
proposal below would break down if two pages tried to increment the cookie
value simultaneously (if both pages changed "cookieValue=3" to
"cookieValue=4" at the same time, the result of your merge step would likely
be "cookieValue=4", not "cookieValue=5" as one might intend).
-atw
On Thu, Sep 3, 2009 at 1:08 PM, Benjamin Smedberg wrote:
> On 9/1/09 7:31 PM, Jeremy Orlow wrote:
>
> > Does the silence mean that no one has any intention of implementing
> > this? If so, maybe we should resign ourselves to a break in the single
> > threaded illusion for cookies. This doesn't seem too outlandish
> > considering that web servers working with cookies will never have such a
> > guarantee and given that we have no evidence of widespread breakage with
> > IE 8 and Chrome.
>
> We (Firefox) just started looking at this seriously: the implications of
> the
> global lock are pretty unpleasant.
>
> The major race condition appears to be code on the web that gets
> document.cookie, parses and modifies the string it to add or remove a
> particular cookie, and sets document.cookie again. This pattern could race
> against HTTP requests which also set cookies.
>
> Chris Jones proposed that we behave in a script-consistent manner without
> actually doing a global mutex:
>
> * When a script gets document.cookie, "check out" a consistent view of the
> cookie data. While the script runs to completion, its view of
> document.cookie does not change.
> * When the script sets document.cookie and runs to completion, calculate
> the
> delta with the original data and "commit" the changes.
> * HTTP Set-Cookie headers stomp on prior data at any time, but don't
> interfere with the consistent script view above.
>
> It would be nice to provide an web API to perform the operation of setting
> a
> cookie atomically, just as the Set-Cookie HTTP header does. That is:
> document.setCookie('foo=bar; domain=subd.example.com').
>
> It's not clear whether/how this same algorithm could be applied to
> localStorage, since the amount of data required to create a consistent
> state
> is potentially much larger. Is there an inherently racy API in
> .localStorage
> which we need to protect with complicate mutex/transactional schemes?
>
> --BDS
>
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
When we had this discussion last, there was significant pushback on this -
the argument was basically "we have no evidence that cookie-based race
conditions *aren't* causing sporadic breakages", which is true. It's
inherently difficult to measure.
As an aside, I'll note that the majority of pushback came from developers of
platforms that were inherently single-threaded, and so enforcing
synchronicity had no impact on the performance of their platforms. It's easy
to be a purist when there's no cost.
Now that more browsers are moving to multi-process architectures and will
soon be faced with having to reduce the performance of their platforms to
enforce cookie coherence, I wonder if people's attitudes have changed. I,
too, would be interested in hearing if the folks working on multi-process
firefox are planning to implement this piece of the spec.
-atw
On Wed, Sep 2, 2009 at 9:55 AM, Darin Fisher wrote:
>
>
> On Tue, Sep 1, 2009 at 4:31 PM, Jeremy Orlow wrote:
>
>> On Wed, Aug 26, 2009 at 3:24 PM, Jeremy Orlow wrote:
>>
>>> On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan >> > wrote:
>>>
On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow wrote:
> Is there any data (or any way to collect the data) on how much of the
> web IE and Chrome's current behavior has broken? Given that there hasn't
> been panic in the streets, I'm assuming approximately 0%?
>
We previously had a lengthy discussion about this.
If a site has a cookie race that causes a problem in IE/Chrome one in
every 10,000 page loads, are you comfortable with that?
>>>
>>> I'm much more comfortable with that than the cost of a global mutex that
>>> all cookies and LocalStorage share. There are other ways to come about this
>>> problem (like developer tools).
>>>
>>> I'm pretty sure Chromium has no intention of implementing a global
>>> storage mutex and putting all cookie access under it. Has anyone heard
>>> anything (either way) from Microsoft? Are there any browsers moving to a
>>> multi-event-loop (be it multi-threaded or multi-process) based model that
>>> intend to implement this? If not, then it would seem like the spec is not
>>> grounded in reality.
>>>
>>
>> Does the silence mean that no one has any intention of implementing this?
>> If so, maybe we should resign ourselves to a break in the single threaded
>> illusion for cookies. This doesn't seem too outlandish considering that web
>> servers working with cookies will never have such a guarantee and given that
>> we have no evidence of widespread breakage with IE 8 and Chrome.
>>
>
> IE 6 <-- it is also multi process. you can poke at wininet from any
> application and change the cookies for IE.
>
> -darin
>
>
>
>> If we were to get rid of the storage mutex for cookie manipulation (as I
>> believe we should) maybe we should re-examine it for local storage. At a
>> minimum, it could be implemented as a per-origin mutex. But I feel strongly
>> we should go further. Why not have an asynchronous mechanism for atomic
>> updates? For example, if I wanted to write an ATM application, I would have
>> to do the following:
>>
>> var accountDelta = /* something */;
>> window.localStorage.executeAtomic(function() {
>> localStorage.accountBalance = localStorage.accountBalance +
>> accountDelta;
>> }
>>
>> Alternatively, we could make it so that each statement is atomic, but that
>> you have to use such a mechanism for anything more complicated. For example:
>>
>> localStorage.accountBalance = localStorage.accountBalance + accountDelta;
>> // It's atomic, so no worries!
>> var balance = localStorage.accountBalance; /* Oh no This isn't safe
>> since it's implemented via multiple statements... */
>> localStorage.accountBalance = balance + accountDelta; /* we should
>> have used localStorage.executeAtomic! */
>>
>> Such ideas would definitely lighten lock contention and possibly eliminate
>> the need for yieldForStorageUpdates (formerly getStorageUpdates). Another
>> major bonus is that it'd allow us to expose localStorage to workers again,
>> which is one of the top complaints I've gotten when talking to web
>> developers about localStorage.
>>
>> I know this is radical stuff, but the way things are speced currently just
>> are not practical.
>>
>> J
>>
>
>
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Tue, Sep 1, 2009 at 4:31 PM, Jeremy Orlow wrote:
> On Wed, Aug 26, 2009 at 3:24 PM, Jeremy Orlow wrote:
>
>> On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan
>> wrote:
>>
>>> On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow wrote:
>>>
Is there any data (or any way to collect the data) on how much of the
web IE and Chrome's current behavior has broken? Given that there hasn't
been panic in the streets, I'm assuming approximately 0%?
>>>
>>> We previously had a lengthy discussion about this.
>>>
>>> If a site has a cookie race that causes a problem in IE/Chrome one in
>>> every 10,000 page loads, are you comfortable with that?
>>>
>>
>> I'm much more comfortable with that than the cost of a global mutex that
>> all cookies and LocalStorage share. There are other ways to come about this
>> problem (like developer tools).
>>
>> I'm pretty sure Chromium has no intention of implementing a global storage
>> mutex and putting all cookie access under it. Has anyone heard anything
>> (either way) from Microsoft? Are there any browsers moving to a
>> multi-event-loop (be it multi-threaded or multi-process) based model that
>> intend to implement this? If not, then it would seem like the spec is not
>> grounded in reality.
>>
>
> Does the silence mean that no one has any intention of implementing this?
> If so, maybe we should resign ourselves to a break in the single threaded
> illusion for cookies. This doesn't seem too outlandish considering that web
> servers working with cookies will never have such a guarantee and given that
> we have no evidence of widespread breakage with IE 8 and Chrome.
>
IE 6 <-- it is also multi process. you can poke at wininet from any
application and change the cookies for IE.
-darin
> If we were to get rid of the storage mutex for cookie manipulation (as I
> believe we should) maybe we should re-examine it for local storage. At a
> minimum, it could be implemented as a per-origin mutex. But I feel strongly
> we should go further. Why not have an asynchronous mechanism for atomic
> updates? For example, if I wanted to write an ATM application, I would have
> to do the following:
>
> var accountDelta = /* something */;
> window.localStorage.executeAtomic(function() {
> localStorage.accountBalance = localStorage.accountBalance +
> accountDelta;
> }
>
> Alternatively, we could make it so that each statement is atomic, but that
> you have to use such a mechanism for anything more complicated. For example:
>
> localStorage.accountBalance = localStorage.accountBalance + accountDelta;
> // It's atomic, so no worries!
> var balance = localStorage.accountBalance; /* Oh no This isn't safe
> since it's implemented via multiple statements... */
> localStorage.accountBalance = balance + accountDelta; /* we should
> have used localStorage.executeAtomic! */
>
> Such ideas would definitely lighten lock contention and possibly eliminate
> the need for yieldForStorageUpdates (formerly getStorageUpdates). Another
> major bonus is that it'd allow us to expose localStorage to workers again,
> which is one of the top complaints I've gotten when talking to web
> developers about localStorage.
>
> I know this is radical stuff, but the way things are speced currently just
> are not practical.
>
> J
>
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Wed, Sep 2, 2009 at 11:31 AM, Jeremy Orlow wrote: > Does the silence mean that no one has any intention of implementing this? > I'm silent because I'm not currently working on this stuff so I can't say what our plans are. But I'll be upset if I find out our plans are to break the single-threaded model. Alternatively, we could make it so that each statement is atomic, but that > you have to use such a mechanism for anything more complicated. For example: > > localStorage.accountBalance = localStorage.accountBalance + accountDelta; > // It's atomic, so no worries! > var balance = localStorage.accountBalance; /* Oh no This isn't safe > since it's implemented via multiple statements... */ > localStorage.accountBalance = balance + accountDelta; /* we should > have used localStorage.executeAtomic! */ > > Such ideas would definitely lighten lock contention and possibly eliminate > the need for yieldForStorageUpdates (formerly getStorageUpdates). Another > major bonus is that it'd allow us to expose localStorage to workers again, > which is one of the top complaints I've gotten when talking to web > developers about localStorage. > > Making what should be (and always have been) meaning-preserving transformations like splitting one JS statement into two no longer meaning-preserving --- and in a non-testable way, to boot --- seems like a pretty bad idea to me. I know this is radical stuff, but the way things are speced currently just > are not practical. > I think that expecting Web developers to reason about concurrency and race conditions is not practical. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Wed, Aug 26, 2009 at 3:24 PM, Jeremy Orlow wrote:
> On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan
> wrote:
>
>> On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow wrote:
>>
>>> Is there any data (or any way to collect the data) on how much of the web
>>> IE and Chrome's current behavior has broken? Given that there hasn't been
>>> panic in the streets, I'm assuming approximately 0%?
>>>
>>
>> We previously had a lengthy discussion about this.
>>
>> If a site has a cookie race that causes a problem in IE/Chrome one in
>> every 10,000 page loads, are you comfortable with that?
>>
>
> I'm much more comfortable with that than the cost of a global mutex that
> all cookies and LocalStorage share. There are other ways to come about this
> problem (like developer tools).
>
> I'm pretty sure Chromium has no intention of implementing a global storage
> mutex and putting all cookie access under it. Has anyone heard anything
> (either way) from Microsoft? Are there any browsers moving to a
> multi-event-loop (be it multi-threaded or multi-process) based model that
> intend to implement this? If not, then it would seem like the spec is not
> grounded in reality.
>
Does the silence mean that no one has any intention of implementing this?
If so, maybe we should resign ourselves to a break in the single threaded
illusion for cookies. This doesn't seem too outlandish considering that web
servers working with cookies will never have such a guarantee and given that
we have no evidence of widespread breakage with IE 8 and Chrome.
If we were to get rid of the storage mutex for cookie manipulation (as I
believe we should) maybe we should re-examine it for local storage. At a
minimum, it could be implemented as a per-origin mutex. But I feel strongly
we should go further. Why not have an asynchronous mechanism for atomic
updates? For example, if I wanted to write an ATM application, I would have
to do the following:
var accountDelta = /* something */;
window.localStorage.executeAtomic(function() {
localStorage.accountBalance = localStorage.accountBalance +
accountDelta;
}
Alternatively, we could make it so that each statement is atomic, but that
you have to use such a mechanism for anything more complicated. For example:
localStorage.accountBalance = localStorage.accountBalance + accountDelta;
// It's atomic, so no worries!
var balance = localStorage.accountBalance; /* Oh no This isn't safe
since it's implemented via multiple statements... */
localStorage.accountBalance = balance + accountDelta; /* we should have
used localStorage.executeAtomic! */
Such ideas would definitely lighten lock contention and possibly eliminate
the need for yieldForStorageUpdates (formerly getStorageUpdates). Another
major bonus is that it'd allow us to expose localStorage to workers again,
which is one of the top complaints I've gotten when talking to web
developers about localStorage.
I know this is radical stuff, but the way things are speced currently just
are not practical.
J
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Wed, Aug 26, 2009 at 3:05 PM, Robert O'Callahan wrote: > On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow wrote: > >> Is there any data (or any way to collect the data) on how much of the web >> IE and Chrome's current behavior has broken? Given that there hasn't been >> panic in the streets, I'm assuming approximately 0%? >> > > We previously had a lengthy discussion about this. > > If a site has a cookie race that causes a problem in IE/Chrome one in every > 10,000 page loads, are you comfortable with that? > I'm much more comfortable with that than the cost of a global mutex that all cookies and LocalStorage share. There are other ways to come about this problem (like developer tools). I'm pretty sure Chromium has no intention of implementing a global storage mutex and putting all cookie access under it. Has anyone heard anything (either way) from Microsoft? Are there any browsers moving to a multi-event-loop (be it multi-threaded or multi-process) based model that intend to implement this? If not, then it would seem like the spec is not grounded in reality.
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow wrote: > Is there any data (or any way to collect the data) on how much of the web > IE and Chrome's current behavior has broken? Given that there hasn't been > panic in the streets, I'm assuming approximately 0%? > We previously had a lengthy discussion about this. If a site has a cookie race that causes a problem in IE/Chrome one in every 10,000 page loads, are you comfortable with that? Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
Is there any data (or any way to collect the data) on how much of the web IE and Chrome's current behavior has broken? Given that there hasn't been panic in the streets, I'm assuming approximately 0%? Given that web developers have never had any guarantees for cookie access/setting in terms of network communications and given that (it sounds like) it won't break the web, maybe we should ditch the idea of locking during cookie access/setting? On Wed, Aug 26, 2009 at 2:42 PM, Drew Wilson wrote: > We discussed this in more detail here: > http://www.mail-archive.com/whatwg@lists.whatwg.org/msg13799.html > > At the time, I suggested not protecting cookies with a mutex (allow > asynchronous access - the current behavior on IE and Chrome), which made the > monocles pop out of everyone's eyes :) > > -atw > > > On Wed, Aug 26, 2009 at 2:21 PM, Jens Alfke wrote: > >> >> On Aug 26, 2009, at 2:11 PM, Drew Wilson wrote: >> >> My recollection is that we prohibit worker access to cookies for exactly >>> this reason (WorkerGlobalScope does not expose a "cookies" attribute). >>> >> >> Looks like you're right; section 5 of the Web Workers spec says: >> >>> The DOM APIs (Node objects, Document objects, etc) are not available to >>> workers in this version of this specification. >>> >>> and there's no defined way to access cookies except through Document. >> Crisis averted. >> >> (If the spec does get modified to allow local-storage access from worker >> threads, though, this same problem will arise, since they use the same >> lock.) >> >> —Jens > > >
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
We discussed this in more detail here: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg13799.html At the time, I suggested not protecting cookies with a mutex (allow asynchronous access - the current behavior on IE and Chrome), which made the monocles pop out of everyone's eyes :) -atw On Wed, Aug 26, 2009 at 2:21 PM, Jens Alfke wrote: > > On Aug 26, 2009, at 2:11 PM, Drew Wilson wrote: > > My recollection is that we prohibit worker access to cookies for exactly >> this reason (WorkerGlobalScope does not expose a "cookies" attribute). >> > > Looks like you're right; section 5 of the Web Workers spec says: > >> The DOM APIs (Node objects, Document objects, etc) are not available to >> workers in this version of this specification. >> >> and there's no defined way to access cookies except through Document. > Crisis averted. > > (If the spec does get modified to allow local-storage access from worker > threads, though, this same problem will arise, since they use the same > lock.) > > —Jens
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
On Aug 26, 2009, at 2:11 PM, Drew Wilson wrote: My recollection is that we prohibit worker access to cookies for exactly this reason (WorkerGlobalScope does not expose a "cookies" attribute). Looks like you're right; section 5 of the Web Workers spec says: The DOM APIs (Node objects, Document objects, etc) are not available to workers in this version of this specification. and there's no defined way to access cookies except through Document. Crisis averted. (If the spec does get modified to allow local-storage access from worker threads, though, this same problem will arise, since they use the same lock.) —Jens
Re: [whatwg] Storage mutex and cookies can lead to browser deadlock
My recollection is that we prohibit worker access to cookies for exactly this reason (WorkerGlobalScope does not expose a "cookies" attribute). -atw On Wed, Aug 26, 2009 at 2:05 PM, Jens Alfke wrote: > I know that one of the design issues with worker threads and local storage > has been how to resolve concurrency issues, and that for this reason, in the > current spec worker threads can't access local storage. > > However, there's a scenario under the current spec that *doesn't* involve > local storage, whereby a worker thread can deadlock the browser. This is > because access to cookies, by workers or the browser itself, is also subject > to that global mutex. > > Consider these steps: > 1. A worker thread accesses "document.cookie". This causes it to acquire > the mutex (sec. 3.1.3). > 2. The thread now performs some long-lasting operation without exiting. In > the simplest case it just goes into an infinite loop. > 3. Meanwhile, the user loads a new web page in the browser. > 4. The resulting HTTP response contains a Cookie: header. The spec requires > that the browser's loader temporarily acquire the mutex while updating the > cookie (sec. 2.6, item 4). > 5. The page-load blocks indefinitely because the worker thread still has > the mutex and never lets go of it. > > The result is that the browser becomes incapable of loading any web pages > that use cookies. Assuming the worker thread never exits, the only way to > recover from this is to quit the browser. A worker thread like this could > very easily be created by a malicious website, resulting in a DoS attack on > the browser. And of course, a merely poorly-written script could create the > same effect without intending to. > > I honestly can't think of any safe way of tweaking the semantics of the > existing 'document.cookie' API to make it transactional. :( > > Has anyone implemented this portion of the spec yet? > > —Jens > >
[whatwg] Storage mutex and cookies can lead to browser deadlock
I know that one of the design issues with worker threads and local storage has been how to resolve concurrency issues, and that for this reason, in the current spec worker threads can't access local storage. However, there's a scenario under the current spec that doesn't involve local storage, whereby a worker thread can deadlock the browser. This is because access to cookies, by workers or the browser itself, is also subject to that global mutex. Consider these steps: 1. A worker thread accesses "document.cookie". This causes it to acquire the mutex (sec. 3.1.3). 2. The thread now performs some long-lasting operation without exiting. In the simplest case it just goes into an infinite loop. 3. Meanwhile, the user loads a new web page in the browser. 4. The resulting HTTP response contains a Cookie: header. The spec requires that the browser's loader temporarily acquire the mutex while updating the cookie (sec. 2.6, item 4). 5. The page-load blocks indefinitely because the worker thread still has the mutex and never lets go of it. The result is that the browser becomes incapable of loading any web pages that use cookies. Assuming the worker thread never exits, the only way to recover from this is to quit the browser. A worker thread like this could very easily be created by a malicious website, resulting in a DoS attack on the browser. And of course, a merely poorly-written script could create the same effect without intending to. I honestly can't think of any safe way of tweaking the semantics of the existing 'document.cookie' API to make it transactional. :( Has anyone implemented this portion of the spec yet? —Jens
