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
