[whatwg] Storage mutex and cookies can lead to browser deadlock

[Jeremy Orlow]

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 <atwilson at google.com> 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 <snej at google.com> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090826/16f4f961/attachment.htm>