On Wed, 4 Nov 2009, Rob Ennals wrote:
How about this for a solution for the localStorage mutex problem: [...]
Here's a proposal based on the recent feedback:
* There is a per-origin mutex. It can be owned by either an event loop
task or a network layer task.
* Things that wait until their
On Wed, Nov 25, 2009 at 6:20 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 4 Nov 2009, Rob Ennals wrote:
How about this for a solution for the localStorage mutex problem: [...]
Here's a proposal based on the recent feedback:
* There is a per-origin mutex. It can be owned by either an
On Wed, Nov 25, 2009 at 6:20 AM, Ian Hickson i...@hixie.ch wrote:
Reading or writing a property on a native object doesn't do it, so
window['x'].document.forms['y'].value = 'foo';
...doesn't release the mutex, though this (identical code) would:
On 11/25/09 6:20 AM, Ian Hickson wrote:
- script calling a method implemented in native code on a host object
...
If this is a MUST, this seems like a possible compat issue depending on
whether the method is native or library-provided, at the very least.
There's also been talk at least
On Wed, Nov 25, 2009 at 9:16 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/25/09 6:20 AM, Ian Hickson wrote:
- script calling a method implemented in native code on a host object
...
If this is a MUST, this seems like a possible compat issue depending on
whether the method is native
On Wed, Nov 25, 2009 at 12:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/25/09 6:20 AM, Ian Hickson wrote:
- script calling a method implemented in native code on a host object
...
If this is a MUST, this seems like a possible compat issue depending on
whether the method is native
On Nov 25, 2009, at 7:46 AM, Jeremy Orlow wrote:
On Wed, Nov 25, 2009 at 6:20 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 4 Nov 2009, Rob Ennals wrote:
How about this for a solution for the localStorage mutex problem:
[...]
Here's a proposal based on the recent feedback:
* There is a
Yes. I think that *any* DOM operation, including getElementById should
be allowed to release the storage mutex. If we start specifying
particular categories of API that do or do not release the mutex then
thing will just get confusing, or we will find that we have missed
something important.
The
On Tue, Nov 24, 2009 at 3:12 PM, Rob Ennals rob.enn...@gmail.com wrote:
Yes. I think that *any* DOM operation, including getElementById should
be allowed to release the storage mutex. If we start specifying
particular categories of API that do or do not release the mutex then
thing will just
On Tue, Nov 24, 2009 at 6:12 PM, Rob Ennals rob.enn...@gmail.com wrote:
If you run your browser in super-warnings-enabled mode then you
could have it warn you if you did anything remotely suspect between
calls to localStorage (e.g. calling a function defined by an external
javascript file or
In spec language, I think it should be MAY release.
In practice, even if it was MUST release, users could potentially see
different behaviour, due to the different scheduling behaviour of
different thread systems etc. Race conditions are inherently
statistical, depending on what happens to be
That's a good point.
I can imagine that this could get particularly noisy if you use a
library which decides to use localStorage itself, and so you aren't
aware that localStorage has been used previously elsewhere.
One simple fix to avoid these warnings would be to introduce two
functions,
On Tue, Nov 24, 2009 at 4:46 PM, Rob Ennals rob.enn...@gmail.com wrote:
In spec language, I think it should be MAY release.
It seems to me that the only difference between what we have now (in
the spec), and your suggestion, would be that implementations could in
more cases claim to follow the
On Wed, Nov 25, 2009 at 2:19 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 24, 2009 at 4:46 PM, Rob Ennals rob.enn...@gmail.com wrote:
In spec language, I think it should be MAY release.
It seems to me that the only difference between what we have now (in
the spec), and your
On Tue, Nov 24, 2009 at 5:24 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, Nov 25, 2009 at 2:19 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 24, 2009 at 4:46 PM, Rob Ennals rob.enn...@gmail.com wrote:
In spec language, I think it should be MAY release.
It seems to me
You are /partly/ correct.
The intention behind this proposal is to have a spec that matches what
implementations do (or that we can reasonably expect that they will
do, given minor effort), so that users know what idioms will work.
It isn't just a matter of PR for implementors. If the spec says
Yeah. Such things could be confusing. Perhaps we would want to
explicitly specify that global variable access does not release the
storage mutex (I'm assuming there is no reason you would ever want it
to do so?).
More generally, the basic principle of this proposal is to specify
what *doesn't*
The planned model is that if you don't want to lose the storage mutex
then you shouldn't call any code that you didn't write yourself. Any
external library (e.g. jquery) should be assumed to release the
storage mutex. Perhaps that should be made explicit in the spec?
We want to guarantee
Since discussion on this topic seems to have calmed down and AFAICT no
fundamental problems were identified, I've now submitted a bugzilla
report suggesting that this change be made to the spec.
-Rob
On Wed, Nov 4, 2009 at 2:13 PM, Rob Ennals rob.enn...@gmail.com wrote:
[this is Rob Ennals from
On Sat, Nov 7, 2009 at 12:08 AM, Chris Jones cjo...@mozilla.com wrote:
Rob Ennals wrote:
Missed out the important final qualifier. Here's take 3:
the user agent MUST NOT release the storage mutex between calls to local
storage, except that the user agent MAY release the storage mutex on any
On Mon, Nov 9, 2009 at 1:42 PM, Adam Barth wha...@adambarth.com wrote:
As I mentioned to Ian at TPAC, one way to make this more predictable
is to release the lock on *every* function call and return. This
provides content enough atomicity to build whatever locks it needs.
Then simple
Rob Ennals wrote:
Missed out the important final qualifier. Here's take 3:
the user agent MUST NOT release the storage mutex between calls to
local storage, except that the user agent MAY release the storage mutex
on any API operation /other that a local storage oeration/
IMHO, this is
user agent MAY release means that people will write code which works
now, and later the browser vendor will make a change that will break
their code. Who is at fault? We all know that the browser vendor is
at fault!
Suggest the user agent SHALL release the storage mutex on any API
operation
By API operation I mean anything other than core ecmascript and
localstorage itself.
Eg you can be sure that the following will not release the mutex:
* do nothing
* function call
* if/for etc
* access to a local variable
* access to a basic ecmascript object (not host objects)
But anything
That version is fine with me.
My reason for using MAY was I thought it would make efficient
implementation easier. Also, testing when things are being unlocked is
pretty much impossible for users due to the statistical nature of race
conditions and shedulers.
But yeah, SHALL is better
[this is Rob Ennals from Intel, posting from gmail over my phone while
at tpac]
How about this for a solution for the localStorage mutex problem:
the user agent MAY release the storage mutex on *any* API operation
except localStorage itself
This guarantees that the common case of several
On Wed, Nov 4, 2009 at 5:13 PM, Rob Ennals rob.enn...@gmail.com wrote:
How about this for a solution for the localStorage mutex problem:
the user agent MAY release the storage mutex on *any* API operation except
localStorage itself
This guarantees that the common case of several storage
The reason we sometimes need to release the storage mutex is to avoid
a deadlock that can occur if a thread holding the storage mutex for
domain X has to wait for another mutex Y - since whoever holds Y might
wait for X, creating a wait cycle. One way to avoid this problem is to
release
On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals rob.enn...@gmail.com wrote:
Or to put it another way: if the thread can't call an API then it can't
block waiting for another storage mutex, thus deadlock can't occur, thus we
don't need to release the storage mutex.
Right, but the spec text there
I suspect my suggested spec line was insufficiently precise. How about
this:
the user agent MUST NOT release the storage mutex between calls to
local storage, except that the user agent MAY release the storage
mutex on any API operation
We'd still need to define what API operation means,
Missed out the important final qualifier. Here's take 3:
the user agent MUST NOT release the storage mutex between calls to
local storage, except that the user agent MAY release the storage
mutex on any API operation /other that a local storage oeration/
If a local storage op can release
31 matches
Mail list logo
