[whatwg] Accessing cookies from workers

Drew Wilson atwilson at google.com
Mon Mar 9 11:07:01 PDT 2009

> 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.

Hmmm, I must've misinterpreted your previous statement:

>>> It seems like it should fine to allow reading cookies in dedicated
>>> workers though.

I'm sure I'm being obtuse, but I don't understand what you are saying here.

Let's imagine that I have a synchronous API - you are saying that this is
bad, because when I do this:

var cookies = self.getAllCookies();

The value of "cookies" may be out of date, so whatever
doSomethingWithCookies() is doing (like invoking an XHR request) may fail
because the cookies aren't accurate.

So, let's assume instead that we allow passing a callback to

self.getAllCookies( function(cookies) { doSomethingWithCookies(cookies); })

When doSomethingWithCookies() is invoked, whatever operation it is
performing may fail, because the passed-in value of cookies may still be out
of date.

Making getAllCookies() asynchronous means that the trivial fail case:

var a = getAllCookies();
var b = getAllCookies();
assert(a === b);

...can no longer fail because there's no return value. But fundamentally the
underlying problem continues to exist - the cookies may have changed behind
the scene, so whatever snapshot you have (either delivered synchronously or
asynchronously) may be out-of-date. So making getAllCookies() asynchronous
does not buy you anything, and additionally makes this API painful to use.

I think it's a laudable goal to try to shield developers from the
intricacies of accessing mutable global state, but I'm not sure that's
possible given that mutable global state exists and we want to allow
applications to access it from multiple threads.

As an aside, I wonder how a multi-process browser like Chrome handles
cookies even in the absence of workers - if I open two windows (separate
processes) under the same domain and set cookies in both, it seems like
there's an existing race condition.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090309/6237ba17/attachment-0002.htm>

More information about the whatwg mailing list