[whatwg] HTML Cookie API

[David Flanagan]

Jeremy Orlow wrote:

> 
> Also note that the spec currently has the notion of a storage mutex 
> which should be taken whenever a script tries to access a cookie (or 
> local storage) and is held until the script finishes.  The network stack 
> is also supposed to take this lock whenever getting or setting a cookie. 
>  No one has implemented the storage mutex or stated any intention of 
> doing so because this is basically impossible today.  But, if there were 
> an asynchronous API that most people were using, it actually could be 
> possible that we'd want to implement such a mutex since cookies would 
> then obey run to completion semantics without having serious lock 
> contention.
> 

Well if no one is going to implement the storage mutex, then I probably 
need to retract my last message

> But yeah.  Definitely any API that touches information spanning tabs 
> (and probably even APIs spanning origins within those tabs) really 
> should be designed in an async manor from now on.  Otherwise we're just 
> digging the whole deeper in terms of forcing ourselves into a single 
> threaded world.
> 
> J

I worry that this comes down to web developers who want simple APIs vs 
browser implementors who say we can't have them (at least not if we also 
want speed.)

Concurrency issues are not my strong suit, but shouldn't it be possible 
to have safe, synchronous read-only access to cookies (caching volatile 
values like cookies within each thread and then clearing that cache when 
the thread returns to the event loop).  Can't the requirement for a 
mutex or an asynchronous API be limited to setCookie()?

	David