[whatwg] Accessing cookies from workers

[Giovanni Campagna]

2009/3/9 Jonas Sicking <jonas at sicking.cc>:
> On Mon, Mar 9, 2009 at 10:18 AM, Drew Wilson <atwilson at google.com> wrote:
>>
>> On Sun, Mar 8, 2009 at 9:59 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>
>>> However a much more interesting question is if sites would break if
>>> the above stopped being true. That is most definitely the case.
>>
>> Agreed - existing behavior trumps spec ambiguity. However, in this case I
>> was assuming that breaking existing sites was not an issue since we're
>> adding completely new functionality (accessing cookies from workers).
>> Existing sites won't break unless they add worker code that modifies
>> cookies, although perhaps that's a situation we need to avoid as well.
>
> I wouldn't expect new sites to be able to cope with this either. Even
> if we put in the spec that the value can change at any time, it is
> extremely unlikely that developers will deal with this appropriately.

They cannot deal with that, given they don't have any syncronization
mechanism outside the event system. To control the value of shared
variables, you need a lock on that variable while you're using it.

> See my analogy earlier in this thread regarding how hard it is to
> write multi-threaded code, even for expert C++ developers. It is
> definitely not something I would expect copy-n-paste web developers to
> get right.

If you don't understand the logics of multithreading, you should not
use workers (that are just ecmascript threads with a message queue),
IMHO.
>
>>> This is a very interesting suggestion. If we add a cookie access API
>>> then this would seem like a reasonable thing to require from that API.
>>>
>>
>> OK, to summarize, the suggestion is that we add something like the following
>> to WorkerGlobalScope:
>>
>> String getAllCookies() - analogous to document.cookies in the DOM world
>
> No, this is a synchronous API which is not acceptible since it creates
> a multithreaded environment for web developers. You need to use a
> callback function.

This can be even worse: how would you syncronize the code in the
callback with code right after the call? You don't have any of
semaphores or mutexes in ES and I don't expect them to be added soon.

> / Jonas
>

Giovanni