[whatwg] Accessing cookies from workers

[Drew Wilson]

So I get what you are saying - from an implementation standpoint, any access
to shared data exposes the asynchronously threaded nature of workers to the
developer, without giving them any tools to manage this access (locks, etc).

For cookies, I'd always assumed that cookie state was mutable, since the
server could set the cookie state via an HTTP response coming down in
parallel with the execution of javascript. Perhaps the spec makes guarantees
about the immutability of document.cookies? It doesn't seem to:

"Otherwise, the user agent must act as it would when processing cookies if
it had just attempted to
fetch<http://www.whatwg.org/specs/web-apps/current-work/#fetch> the
document's address<http://www.whatwg.org/specs/web-apps/current-work/#the-document%27s-address>over
HTTP, and had received a response with a
Set-Cookie header whose value was the specified value, as per RFC 2109
sections 4.3.1, 4.3.2, and 4.3.3 or later specifications, but without
overwriting the values of HTTP-only cookies.
[RFC2109]<http://www.whatwg.org/specs/web-apps/current-work/#refsRFC2109>
[RFC2965] <http://www.whatwg.org/specs/web-apps/current-work/#refsRFC2965>"

It seems like developers shouldn't be depending on the value of
document.cookie being static anyway.

-atw

On Thu, Mar 5, 2009 at 5:55 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Thu, Mar 5, 2009 at 5:44 PM, Drew Wilson <atwilson at google.com> wrote:
> > So an asynchronous cookie setting API would look like:
> >
> > setCookie(cookieStr, callback)
> >
> > ...where the callback is invoked once the cookie has been set?
> >
> > I guess I don't yet entirely understand the implementation details - it
> > sounds like there are problems accessing any shared state between workers
> > and window context?
>
> The problem is with code like the following:
>
> if (sharedState < 0) {
>  sharedState = sharedState * -1;
> }
>
> You would expect sharedState to always be non-negative at the end of
> such a program, right? Well, that might not be the case since script
> running in parallel in the main window might have changed the value of
> sharedState from -5 to 10 between the if-statement and the assignment,
> resulting in sharedState being -10 at the end.
>
> This is why workers use a shared-nothing message passing interface
> between workers and windows. This is something that simply can't be
> fixed in the implementation, but something that scripts would have to
> deal with themselves. It's unlikely that web developers would do this
> correctly since working with threads is *very hard* and something that
> even seasoned developers often get wrong.
>
> / Jonas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090305/f47b0479/attachment-0002.htm>