Re: [chromium-html5] LocalStorage inside Worker
2011/1/7 Jonas Sicking jo...@sicking.cc: On Thu, Jan 6, 2011 at 7:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/6/11 5:25 PM, João Eiras wrote: Not different from two different tabs/windows running the same code. In which current browsers do same-origin tabs/windows end up interleaving their JS (that is, one runs JS before the other has returned to the event loop)? I'm fairly sure it happens both in Chrome and IE. One way it can happen is: Tab 1 opens with a page from site A Tab 2 opens with a page from site B The page in tab 2 contains an iframe with a page from site A. But I'm not even sure that Chrome and IE makes an effort to use the same process if you open two tabs for the same site. It seemed that Chrome doesn't interleave the JS when the same page is opened in multiple tabs. Try running this script in multiple tabs and monitor the console output: http://felix-halim.net/interleave.html In Chrome console log, you will see many FAIL, but not in Firefox. So does this mean localStorage in Chrome is broken? or this is an intended behavior? Felix Halim
Re: [chromium-html5] LocalStorage inside Worker
On Thu, Jan 27, 2011 at 12:39 AM, Felix Halim felix.ha...@gmail.com wrote: 2011/1/7 Jonas Sicking jo...@sicking.cc: On Thu, Jan 6, 2011 at 7:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/6/11 5:25 PM, João Eiras wrote: Not different from two different tabs/windows running the same code. In which current browsers do same-origin tabs/windows end up interleaving their JS (that is, one runs JS before the other has returned to the event loop)? I'm fairly sure it happens both in Chrome and IE. One way it can happen is: Tab 1 opens with a page from site A Tab 2 opens with a page from site B The page in tab 2 contains an iframe with a page from site A. But I'm not even sure that Chrome and IE makes an effort to use the same process if you open two tabs for the same site. It seemed that Chrome doesn't interleave the JS when the same page is opened in multiple tabs. Try running this script in multiple tabs and monitor the console output: http://felix-halim.net/interleave.html In Chrome console log, you will see many FAIL, but not in Firefox. So does this mean localStorage in Chrome is broken? or this is an intended behavior? Although the updates to localStorage are interleaved, the two tabs are not: both are running in different processess/event-loops. I.e. they run parallel. i.e. localStorage (and cookies) don't support run to completion. We don't implement the storage mutex as specced because it'd severely limit this concurrency. If you search the archives, you'll find a lot of discussions about this. If this is a problem for you, then I suggest you look at WebSQLDatabase or (soon) IndexedDB. J
Re: [chromium-html5] LocalStorage inside Worker
On Jan 27, 2011, at 11:01 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Jan 27, 2011 at 12:39 AM, Felix Halim felix.ha...@gmail.com wrote: 2011/1/7 Jonas Sicking jo...@sicking.cc: On Thu, Jan 6, 2011 at 7:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/6/11 5:25 PM, João Eiras wrote: Not different from two different tabs/windows running the same code. In which current browsers do same-origin tabs/windows end up interleaving their JS (that is, one runs JS before the other has returned to the event loop)? I'm fairly sure it happens both in Chrome and IE. One way it can happen is: Tab 1 opens with a page from site A Tab 2 opens with a page from site B The page in tab 2 contains an iframe with a page from site A. But I'm not even sure that Chrome and IE makes an effort to use the same process if you open two tabs for the same site. It seemed that Chrome doesn't interleave the JS when the same page is opened in multiple tabs. Try running this script in multiple tabs and monitor the console output: http://felix-halim.net/interleave.html In Chrome console log, you will see many FAIL, but not in Firefox. So does this mean localStorage in Chrome is broken? or this is an intended behavior? Although the updates to localStorage are interleaved, the two tabs are not: both are running in different processess/event-loops. I.e. they run parallel. i.e. localStorage (and cookies) don't support run to completion. We don't implement the storage mutex as specced because it'd severely limit this concurrency. If you search the archives, you'll find a lot of discussions about this. If this is a problem for you, then I suggest you look at WebSQLDatabase or (soon) IndexedDB. J FWIW: websql is mostly abandoned, though super handy on ios mobile devices. IndexedDB is live in Chrome, Firefox and the MS interop team released a prototype for IE. Moz and webkit both just implement IDB atop of their internal sqlite processes. That is, thy create a simple websql schema. Afaik, websql does not support blobs.
Re: [chromium-html5] LocalStorage inside Worker
Afaik, websql does not support blobs. If stored as strings, it does. sqlite treats TEXT as an opaque buffer.
Re: [chromium-html5] LocalStorage inside Worker
On Thu, Jan 27, 2011 at 12:06 PM, Charles Pritchard ch...@visc.us wrote: FWIW: websql is mostly abandoned, though super handy on ios mobile devices. It's been around for a while in everything other than FF and IE. IndexedDB is live in Chrome, Firefox and the MS interop team released a prototype for IE. For the record, we haven't shipped it to stable yet, though we do have a version in the dev channel. We're hoping to ship before long though (once we get the API back up to date). Moz and webkit both just implement IDB atop of their internal sqlite processes. That is, thy create a simple websql schema. For now, yes. It's actually pretty fast though! On Thu, Jan 27, 2011 at 12:31 PM, João Eiras joao-c-ei...@telecom.pt wrote: Afaik, websql does not support blobs. If stored as strings, it does. sqlite treats TEXT as an opaque buffer. Not all binary can be expressed at UTF16. Note that this is also a limitation of LocalStorage as well. J
Re: [chromium-html5] LocalStorage inside Worker
On Thursday 27 January 2011 20:39:50 you wrote:
On Thu, Jan 27, 2011 at 12:06 PM, Charles Pritchard
ch...@visc.usmailto:ch...@visc.us wrote:
FWIW: websql is mostly abandoned, though super handy on ios mobile devices.
It's been around for a while in everything other than FF and IE.
IndexedDB is live in Chrome, Firefox and the MS interop team released a
prototype for IE.
For the record, we haven't shipped it to stable yet, though we do have a
version in the dev channel. We're hoping to ship before long though (once we
get the API back up to date).
Moz and webkit both just implement IDB atop of their internal sqlite
processes. That is, thy create a simple websql schema.
For now, yes. It's actually pretty fast though!
On Thu, Jan 27, 2011 at 12:31 PM, João Eiras
joao-c-ei...@telecom.ptmailto:joao-c-ei...@telecom.pt wrote:
Afaik, websql does not support blobs.
If stored as strings, it does. sqlite treats TEXT as an opaque buffer.
Not all binary can be expressed at UTF16. Note that this is also a
limitation of LocalStorage as well.
UTF16 represents the character table user agents use when displaying a buffer
of text, because nothing prevents you from doing:
# localStorage.setItem('foobar', \0\xff\ufeff);
# alert(escape(localStorage.getItem('foobar')));
Works in Opera at least, including in web sql dbs.
Re: [chromium-html5] LocalStorage inside Worker
On Thu, Jan 27, 2011 at 12:47 PM, João Eiras joao-c-ei...@telecom.ptwrote:
On Thursday 27 January 2011 20:39:50 you wrote:
On Thu, Jan 27, 2011 at 12:06 PM, Charles Pritchard ch...@visc.us
mailto:ch...@visc.us wrote:
FWIW: websql is mostly abandoned, though super handy on ios mobile
devices.
It's been around for a while in everything other than FF and IE.
IndexedDB is live in Chrome, Firefox and the MS interop team released a
prototype for IE.
For the record, we haven't shipped it to stable yet, though we do have a
version in the dev channel. We're hoping to ship before long though (once
we get the API back up to date).
Moz and webkit both just implement IDB atop of their internal sqlite
processes. That is, thy create a simple websql schema.
For now, yes. It's actually pretty fast though!
On Thu, Jan 27, 2011 at 12:31 PM, João Eiras joao-c-ei...@telecom.pt
mailto:joao-c-ei...@telecom.pt wrote:
Afaik, websql does not support blobs.
If stored as strings, it does. sqlite treats TEXT as an opaque buffer.
Not all binary can be expressed at UTF16. Note that this is also a
limitation of LocalStorage as well.
UTF16 represents the character table user agents use when displaying a
buffer of text, because nothing prevents you from doing:
# localStorage.setItem('foobar', \0\xff\ufeff);
# alert(escape(localStorage.getItem('foobar')));
Works in Opera at least, including in web sql dbs.
Works in Chrome as well. (Didn't try WebSQLDatabase.)
Nevertheless, I would expect any code doing stuff like this to be fairly
fragile. And in general, I'd probably recommend not doing it unless you
really need to.
J
Re: [chromium-html5] LocalStorage inside Worker
On Jan 27, 2011, at 12:47 PM, João Eiras joao-c-ei...@telecom.pt wrote:
On Thursday 27 January 2011 20:39:50 you wrote:
On Thu, Jan 27, 2011 at 12:06 PM, Charles Pritchard
ch...@visc.usmailto:ch...@visc.us wrote:
FWIW: websql is mostly abandoned, though super handy on ios mobile devices.
It's been around for a while in everything other than FF and IE.
IndexedDB is live in Chrome, Firefox and the MS interop team released a
prototype for IE.
For the record, we haven't shipped it to stable yet, though we do have a
version in the dev channel. We're hoping to ship before long though (once
we get the API back up to date).
Moz and webkit both just implement IDB atop of their internal sqlite
processes. That is, thy create a simple websql schema.
For now, yes. It's actually pretty fast though!
On Thu, Jan 27, 2011 at 12:31 PM, João Eiras
joao-c-ei...@telecom.ptmailto:joao-c-ei...@telecom.pt wrote:
Afaik, websql does not support blobs.
If stored as strings, it does. sqlite treats TEXT as an opaque buffer.
Not all binary can be expressed at UTF16. Note that this is also a
limitation of LocalStorage as well.
UTF16 represents the character table user agents use when displaying a buffer
of text, because nothing prevents you from doing:
# localStorage.setItem('foobar', \0\xff\ufeff);
# alert(escape(localStorage.getItem('foobar')));
Works in Opera at least, including in web sql
It's a poorly performing mechanism for binary resources such as images.
We use base64 data uris: it's a big performance hit compared to createObjectUrl
Blob/FileSystem.
Re: [chromium-html5] LocalStorage inside Worker
I think the idea is that JavaScript should not do unexpected things. The suggestion to only make local storage accessible from inside callbacks seems the best suggestion so far. Cheers, Keean. On 11 January 2011 06:20, Felix Halim felix.ha...@gmail.com wrote: On Tue, Jan 11, 2011 at 1:02 PM, Glenn Maynard gl...@zewt.org wrote: localStorage should focus on simplicity and performance and ignore thread safety since, IMHO, localStorage is used for UI purposes or preferences settings (not data itself). If you open two tab, you change settings in one tab, you can just refresh the other tab and I believe both of them will have the same UI state again. It's used for data storage, too, particularly since it's widely available in production; IndexedDB is not. Then, why don't introduce a new storage, like localStorageNTS (NTS = non thread safe), and allow this storage to be used everywhere... Felix Halim
Re: [chromium-html5] LocalStorage inside Worker
I think I already came to the same conclusion... JavaScript has no control over effects, which devalues STM. In the absence of effect control, apparent serialisation (of transactions) is the best you can do. What we need is a purely functional JavaScript, it makes threading so much easier ;-) Cheers, Keean. On 10 January 2011 23:42, Robert O'Callahan rob...@ocallahan.org wrote: STM is not a panacea. Read http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspxif you haven't already. In Haskell, where you have powerful control over effects, it may work well, but Javascript isn't anything like that. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [chromium-html5] LocalStorage inside Worker
So what's the plan for localStorage in workers? J On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke ke...@fry-it.com wrote: I think I already came to the same conclusion... JavaScript has no control over effects, which devalues STM. In the absence of effect control, apparent serialisation (of transactions) is the best you can do. What we need is a purely functional JavaScript, it makes threading so much easier ;-) Cheers, Keean. On 10 January 2011 23:42, Robert O'Callahan rob...@ocallahan.org wrote: STM is not a panacea. Read http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspxif you haven't already. In Haskell, where you have powerful control over effects, it may work well, but Javascript isn't anything like that. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [chromium-html5] LocalStorage inside Worker
With localStorage being the way it is, I personally don't think we can ever allow localStorage access in workers. However I do think we can and should provide access to a separate storage area (or several named storage areas) which can only be accessed from callbacks. On the main thread those callbacks would be asynchronous. In workers those callbacks can be either synchronous or asynchronous. Here is the API I'm proposing: getNamedStorage(in DOMString name, in Function callback); getNamedStorageSync(in DOMString name, in Function callback); The latter is only available in workers. The former is available in both workers and in windows. When the callback is called it's given a reference to the Storage object which has the exact same API as localStorage does. Also, you're not allowed to nest getNamedStorageSync and/or IDBDatabaseSync.transaction calls. This has the added advantage that it's much more implementable without threading hazards than localStorage already is. / Jonas On Tue, Jan 11, 2011 at 6:40 AM, Jeremy Orlow jor...@chromium.org wrote: So what's the plan for localStorage in workers? J On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke ke...@fry-it.com wrote: I think I already came to the same conclusion... JavaScript has no control over effects, which devalues STM. In the absence of effect control, apparent serialisation (of transactions) is the best you can do. What we need is a purely functional JavaScript, it makes threading so much easier ;-) Cheers, Keean. On 10 January 2011 23:42, Robert O'Callahan rob...@ocallahan.org wrote: STM is not a panacea. Read http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx if you haven't already. In Haskell, where you have powerful control over effects, it may work well, but Javascript isn't anything like that. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [chromium-html5] LocalStorage inside Worker
Would each 'name' storage have its own thread to improve parallelism?
would:
withNamedStorage('x', function(store) {...});
make more sense from a naming point of view?
Cheers,
Keean.
On 11 January 2011 20:58, Jonas Sicking jo...@sicking.cc wrote:
With localStorage being the way it is, I personally don't think we can
ever allow localStorage access in workers.
However I do think we can and should provide access to a separate
storage area (or several named storage areas) which can only be
accessed from callbacks. On the main thread those callbacks would be
asynchronous. In workers those callbacks can be either synchronous or
asynchronous. Here is the API I'm proposing:
getNamedStorage(in DOMString name, in Function callback);
getNamedStorageSync(in DOMString name, in Function callback);
The latter is only available in workers. The former is available in
both workers and in windows. When the callback is called it's given a
reference to the Storage object which has the exact same API as
localStorage does.
Also, you're not allowed to nest getNamedStorageSync and/or
IDBDatabaseSync.transaction calls.
This has the added advantage that it's much more implementable without
threading hazards than localStorage already is.
/ Jonas
On Tue, Jan 11, 2011 at 6:40 AM, Jeremy Orlow jor...@chromium.org wrote:
So what's the plan for localStorage in workers?
J
On Tue, Jan 11, 2011 at 9:10 AM, Keean Schupke ke...@fry-it.com wrote:
I think I already came to the same conclusion... JavaScript has no
control
over effects, which devalues STM. In the absence of effect control,
apparent
serialisation (of transactions) is the best you can do.
What we need is a purely functional JavaScript, it makes threading so
much
easier ;-)
Cheers,
Keean.
On 10 January 2011 23:42, Robert O'Callahan rob...@ocallahan.org
wrote:
STM is not a panacea. Read
http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx
if you haven't already.
In Haskell, where you have powerful control over effects, it may work
well, but Javascript isn't anything like that.
Rob
--
Now the Bereans were of more noble character than the Thessalonians,
for
they received the message with great eagerness and examined the
Scriptures
every day to see if what Paul said was true. [Acts 17:11]
Re: [chromium-html5] LocalStorage inside Worker
On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke ke...@fry-it.com wrote:
Would each 'name' storage have its own thread to improve parallelism?
Your vocabulary is a bit off since from an API point of view, storage
areas don't have threads, the execution environments in workers and
windows do.
But if your question is weather one worker can open the storage named
foo, while another window or worker is holding the storage named
bar open, then the answer is yes.
would:
withNamedStorage('x', function(store) {...});
make more sense from a naming point of view?
I have a different association for 'with', especially in context of
JavaScript, so I prefer 'get'. But others feel free to express an
opinion.
/ Jonas
Re: [chromium-html5] LocalStorage inside Worker
On Tue, Jan 11, 2011 at 2:37 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jan 11, 2011 at 2:11 PM, Keean Schupke ke...@fry-it.com wrote:
would:
withNamedStorage('x', function(store) {...});
make more sense from a naming point of view?
I have a different association for 'with', especially in context of
JavaScript, so I prefer 'get'. But others feel free to express an
opinion.
In the context of other languages with similar constructs (request a
resource which is available within the body of the construct), the
with[resource] naming scheme is pretty common and well-known. I
personally like it.
~TJ
Re: [chromium-html5] LocalStorage inside Worker
On Tue, Jan 11, 2011 at 9:02 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Python has its with keyword, used like with file = open('foo'):
doStuffToTheFile(file), which similarly creates a named resource and
(with open('foo') as file:)
takes a chunk of code within which the resource is available. I know
that other languages have similar, but off the top of my head I'm
having trouble thinking of them.
For what it's worth, my first reaction to withNamedStorage was that
it felt like the vocabulary of another language transplanted into
Javascript, and that it felt out of place.
That may be due to there being no comparable APIs like this in
Javascript yet (that I can think of) rather than the vocabulary
describing it, though.
--
Glenn Maynard
Re: [chromium-html5] LocalStorage inside Worker
STM is not a panacea. Read http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspxif you haven't already. In Haskell, where you have powerful control over effects, it may work well, but Javascript isn't anything like that. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [chromium-html5] LocalStorage inside Worker
Looking through all these complexities, I'm wondering why do we need to make localStorage thread safe in the first place? I mean, we can always switch to IndexedDB if we want thread safe storage. localStorage should focus on simplicity and performance and ignore thread safety since, IMHO, localStorage is used for UI purposes or preferences settings (not data itself). If you open two tab, you change settings in one tab, you can just refresh the other tab and I believe both of them will have the same UI state again. So what's the justification of making localStorage thread safe? Felix Halim On Tue, Jan 11, 2011 at 6:42 AM, Robert O'Callahan rob...@ocallahan.org wrote: STM is not a panacea. Read http://www.bluebytesoftware.com/blog/2010/01/03/ABriefRetrospectiveOnTransactionalMemory.aspx if you haven't already. In Haskell, where you have powerful control over effects, it may work well, but Javascript isn't anything like that. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [chromium-html5] LocalStorage inside Worker
On Tue, Jan 11, 2011 at 12:26 AM, Felix Halim felix.ha...@gmail.com wrote: Looking through all these complexities, I'm wondering why do we need to make localStorage thread safe in the first place? I mean, we can always switch to IndexedDB if we want thread safe storage. I don't think Jonas's suggestion is complex. (It's certainly less convenient, but I think that's bearable.) localStorage should focus on simplicity and performance and ignore thread safety since, IMHO, localStorage is used for UI purposes or preferences settings (not data itself). If you open two tab, you change settings in one tab, you can just refresh the other tab and I believe both of them will have the same UI state again. It's used for data storage, too, particularly since it's widely available in production; IndexedDB is not. So what's the justification of making localStorage thread safe? I think the general goal is simply to have as few side-effects of external things happening while Javascript code is running as possible. Wherever you eliminate that, you eliminate potential race conditions. -- Glenn Maynard
Re: [chromium-html5] LocalStorage inside Worker
On Tue, Jan 11, 2011 at 1:02 PM, Glenn Maynard gl...@zewt.org wrote: localStorage should focus on simplicity and performance and ignore thread safety since, IMHO, localStorage is used for UI purposes or preferences settings (not data itself). If you open two tab, you change settings in one tab, you can just refresh the other tab and I believe both of them will have the same UI state again. It's used for data storage, too, particularly since it's widely available in production; IndexedDB is not. Then, why don't introduce a new storage, like localStorageNTS (NTS = non thread safe), and allow this storage to be used everywhere... Felix Halim
Re: [chromium-html5] LocalStorage inside Worker
On 8 January 2011 00:57, Glenn Maynard gl...@zewt.org wrote: On Thu, Jan 6, 2011 at 6:06 PM, Charles Pritchardch...@jumis.com wrote: I don't think localStorage should be (to web workers), but sessionStorage seems a reasonable request. It's not arbitrary: the names local and session convey some meaning. localStorage works well enough, out in the wild. sessionStorage is not in wide use. I don't think it's restrictive, it just creates a wider implementation divide between session and local. What I meant was: you said that you don't think localStorage should be available to workers, but I don't understand why. Why should sessionStorage be available, but localStorage not? -- Glenn Maynard There is also the issue that current localStorage implementations may be broken by multiple tabs/windows. To say it works well enough in the wild seems to ignore this brokenness. If access had to be from inside an atomic block (a callback from a single storage-thread) then this would fix access from multiple tabs/windows as well as from worker threads. This could be implemented as a single threaded callback serialising access to the storage, but implementers could choose to use Software Transactional Memory techniques to give their browser a speed advantage. Cheers, Keean.
Re: [chromium-html5] LocalStorage inside Worker
On Sat, Jan 8, 2011 at 4:06 AM, Keean Schupke ke...@fry-it.com wrote: If access had to be from inside an atomic block (a callback from a single storage-thread) then this would fix access from multiple tabs/windows as well as from worker threads. Your suggestion and Jonas's are very similar. I think the difference is that you're suggesting an API that would permit non-serialized access to the objects, by using transactional methods, where Jonas's completely serializes access. Jonas's is much simpler; I don't think the complexity of this type of transactional access is needed, or appropriate for simple Storage objects. -- Glenn Maynard
Re: [chromium-html5] LocalStorage inside Worker
On 8 January 2011 10:00, Glenn Maynard gl...@zewt.org wrote: On Sat, Jan 8, 2011 at 4:06 AM, Keean Schupke ke...@fry-it.com wrote: If access had to be from inside an atomic block (a callback from a single storage-thread) then this would fix access from multiple tabs/windows as well as from worker threads. Your suggestion and Jonas's are very similar. I think the difference is that you're suggesting an API that would permit non-serialized access to the objects, by using transactional methods, where Jonas's completely serializes access. Jonas's is much simpler; I don't think the complexity of this type of transactional access is needed, or appropriate for simple Storage objects. -- Glenn Maynard I am suggesting that as the semantics are the same, People can think of this like serialised access, but implementers can use STMs to make their browser faster than the competition (if they want). To the user it will look the same. Cheers, Keean.
Re: [chromium-html5] LocalStorage inside Worker
So long as you only allow asynchronous access the implementation can ensure that a worker and the main thread doesn't have access to the storage at the same time. Then it is safe to allow everyone to modify the storage area. / Jonas This is true, serialising access would have the same semantics as STM. Infact you could consider STM to be a performance enhancement to sequential access by optimistically allowing concurrent modifications and only doing something special if there is a collision (a read from a location written by another thread during the transaction). In which case STM works like a database and rolls back the transaction. It is really putting a thread local log between the user and the storage. The main storage is then only locked during the log commit, reducing resource contention. A rollback is simply discarding the log. But this would behave identically (apart from the extra features in STM like guards and retry) to serialisation of requests. A simple (non STM) implementation would be to have a single thread associated with the localStorage and require all accesses to be executed by that thread (in callbacks). You could use the main UI thread, but it would make worker threads wait for storage access during DOM processing in callbacks etc... Cheers, Keean.
Re: [chromium-html5] LocalStorage inside Worker
On Fri, Jan 7, 2011 at 4:58 PM, Glenn Maynard gl...@zewt.org wrote:
A solution that makes localStorage read-only in workers is no solution.
If the current implementation of localStorage is broken by opening two
tabs, then why not allow workers to access the localStorage already?
As you have mentioned, it is no different than opening several more
tabs. So, assuming the localStorage is consistent even with multiple
tabs open, the remaining problem is dealing with the workers' access.
I fail to see why making a read-only localStorage in workers is a no
solution?
Thanks to Keean's pointer, I dug up a short but really helpful STM talk:
http://blip.tv/file/get/OSCON-OSCON2007SimonPeytonJones914.mov
Go back to the multiple tabs problem: if we opened 10 tabs, then the
interleaving JS (mentioned by Boris) may degrade the performance by
10 times. In this case, perhaps we need STM (those who use STM will
gain performance, those who don't will fallback to interleaving JS)?
On Fri, Jan 7, 2011 at 5:33 PM, Keean Schupke ke...@fry-it.com wrote:
- It solves the efficiency problem
From the video, I see that while optimistic is good for performance,
in the same way it's bad for performance since it have to keep a log
(for rollback). I believe Jonas' getBetterStorage doesn't need to
maintain a log as it is assumed that it never have to
retry/rollback/fail, but it is executed single-threadedly. Application
specific benchmark is needed... but I believe both will be efficient
enough.
It also has the following advantages (quoted from the tutorial I posted):
- No race conditions due to forgotten locks
Race conditions still happen if you (jarringly) forgot to wrap your
shared object inside atomic block :P. So, maybe it's a good idea to
only allow localStorage to be accessed inside an atomic block (even in
workers)?
On Fri, Jan 7, 2011 at 5:39 PM, Keean Schupke ke...@fry-it.com wrote:
Ok. But what i'm trying to say is, forcing the localStorage to use
atomic block is a bad idea in the main page thread since a
transaction in the main page thread can span very long time perhaps
committed by a click event.
How is this any different from having a big loop an any callback:
var onclick = fuction() {
for (i = 0; i 10; i++) {
// do some work
}
}
I've just made the page non-responsive...
Also notice:
atomic(function(state) {...})
The commit happens automatically when the callback function returns, so a
split transaction (the commit in a callback) is impossible with this
formulation. Just think about the lexical-scoping.
An example of a long transaction that committed in a callback is:
you are committing based on the return value of an AJAX call... and to
make that AJAX call, you require to be inside atomic block while
reading some shared value... I know it's a bad example, but it's one
of the idea of the long transaction I mentioned. So I guess atomic
doesn't span to a very long transaction (it does not necessarily
need to make the browser unresponsive).
But I agree, for short transactions, it looks simple and perfect.
In the video, the proposed atomic is blocking. So, perhaps the
Javascript API needs to supply a callback (for non-blocking) to be
called after the atomic routine is finished?
Felix Halim
Re: [chromium-html5] LocalStorage inside Worker
Race conditions still happen if you (jarringly) forgot to wrap your
shared object inside atomic block :P. So, maybe it's a good idea to
only allow localStorage to be accessed inside an atomic block (even in
workers)?
Yes, that was in my original suggestion.
atomic(function(shared) {...});
The callback scoped variable shared is the only way to access the shared
namespace.
Cheers,
Keean.
Re: [chromium-html5] LocalStorage inside Worker
On 1/6/2011 3:20 PM, Jonas Sicking wrote: On Thu, Jan 6, 2011 at 3:06 PM, Charles Pritchardch...@jumis.com wrote: Shouldn't sessionStorage be made accessible? I don't think localStorage should be (to web workers), but sessionStorage seems a reasonable request. Why wouldn't that have the same threading issues as I described? There a good reason for it to have those issues in sessionStorage. localStorage need not. At least when it comes to workers. They use synchronous interfaces in the File API, too. Would you rather File API be used to create locks? Keep in mind that sessionStorage is limited to 5 megs: these are reasonably small areas of memory, and they're not written to that often. On 1/6/2011 4:19 PM, Glenn Maynard wrote: On Thu, Jan 6, 2011 at 6:06 PM, Charles Pritchardch...@jumis.com wrote: Shouldn't sessionStorage be made accessible? I don't think localStorage should be (to web workers), but sessionStorage seems a reasonable request. Why? I've wanted to access localStorage from workers in the past, and if the details for accessing Storage objects are worked out at all, then exposing sessionStorage but not localStorage seems arbitrary and unnecessarily restrictive. It's not arbitrary: the names local and session convey some meaning. localStorage works well enough, out in the wild. sessionStorage is not in wide use. I don't think it's restrictive, it just creates a wider implementation divide between session and local. You can still use your main thread to loop through session storage and copy it into local storage.
Re: [chromium-html5] LocalStorage inside Worker
On Thu, Jan 6, 2011 at 6:06 PM, Charles Pritchardch...@jumis.com wrote: I don't think localStorage should be (to web workers), but sessionStorage seems a reasonable request. It's not arbitrary: the names local and session convey some meaning. localStorage works well enough, out in the wild. sessionStorage is not in wide use. I don't think it's restrictive, it just creates a wider implementation divide between session and local. What I meant was: you said that you don't think localStorage should be available to workers, but I don't understand why. Why should sessionStorage be available, but localStorage not? -- Glenn Maynard
Re: [chromium-html5] LocalStorage inside Worker
public-webapps is probably the better place for this email On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim felix.ha...@gmail.com wrote: I know this has been discussed 1 year ago: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14087.html I couldn't find the follow up, so I guess localStorage is still inaccessible from Workers? Yes. I have one other option aside from what mentioned by Jeremy: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14075.html 5: Why not make localStorage accessible from the Workers as read only ? The use case is as following: First, the user in the main window page (who has read/write access to localStorage), dumps a big data to localStorage. Once all data has been set, then the main page spawns Workers. These workers read the data from localStorage, process it, and returns via message passing (as they cannot alter the localStorage value). What are the benefits? 1. No lock, no deadlock, no data race, fast, and efficient (see #2 below). 2. You only set the data once, read by many Worker threads (as opposed to give the big data again and again from the main page to each of the Workers via message). 3. It is very easy to use compared to using IndexedDB (i'm the big proponent in localStorage). Note: I was not following the discussion on the spec, and I don't know if my proposal has been discussed before? or is too late to change now? I don't think it's too late or has had much discussion any time recently. It's probably worth re-exploring. Thanks, Felix Halim
Re: [chromium-html5] LocalStorage inside Worker
On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim felix.ha...@gmail.com wrote:
I know this has been discussed 1 year ago:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14087.html
I couldn't find the follow up, so I guess localStorage is still
inaccessible from Workers?
I've been frustrated by the lack of access to localStorage in workers,
too, and somewhat confused, since this seems like a basic API that
people would expect to be able to access from workers.
It seems like the underlying goal is to prevent localStorage from
changing out from under a script while it's running. But, that's what
currently happens with localStorage in most (all?) browsers. From
reading other threads on this, it seems like nobody expects the
localStorage mutex to ever be implemented in most browsers. Doesn't
that indicate that it should be replaced with something that will
eventually match reality?
The main thing that would be nice to have, when async changes can
happen, is a way to atomically set multiple properties:
localStorage.update({field1: 1, field2: 2});
to prevent concurrent updates to multiple fields leaving localStorage
in an unexpected state, and to prevent other threads reading
localStorage from seeing partially-updated data.
--
Glenn Maynard
Re: [chromium-html5] LocalStorage inside Worker
On Thu, Jan 6, 2011 at 12:01 PM, Jeremy Orlow jor...@chromium.org wrote:
public-webapps is probably the better place for this email
On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim felix.ha...@gmail.com wrote:
I know this has been discussed 1 year ago:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14087.html
I couldn't find the follow up, so I guess localStorage is still
inaccessible from Workers?
Yes.
I have one other option aside from what mentioned by Jeremy:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14075.html
5: Why not make localStorage accessible from the Workers as read only ?
The use case is as following:
First, the user in the main window page (who has read/write access to
localStorage), dumps a big data to localStorage. Once all data has
been set, then the main page spawns Workers. These workers read the
data from localStorage, process it, and returns via message passing
(as they cannot alter the localStorage value).
What are the benefits?
1. No lock, no deadlock, no data race, fast, and efficient (see #2 below).
2. You only set the data once, read by many Worker threads (as opposed
to give the big data again and again from the main page to each of the
Workers via message).
3. It is very easy to use compared to using IndexedDB (i'm the big
proponent in localStorage).
Note: I was not following the discussion on the spec, and I don't know
if my proposal has been discussed before? or is too late to change
now?
I don't think it's too late or has had much discussion any time recently.
It's probably worth re-exploring.
Unfortunately this is not possible. Since localStorage is
synchronously accessed, if we allowed workers to access it that would
mean that we no longer have a shared-nothing-message-passing threading
model. Instead we'd have a shared memory threading model which would
require locks, mutexes, etc.
Making it readonly unfortunately doesn't help. Consider worker code like:
var x = 0;
if (localStorage.foo 10) {
x += localStorage.foo;
}
would you expect x ever being something other than 0 or 1?
That said. As I have suggested before (don't remember if it was here
or on the whatwg list), if we create a new version of localStorage,
where you can only get a reference to the localStorage object
asynchronously, then we should be fine. So something like:
var s;
getBetterStorage(function(storage) {
storage.foo += storage.bar;
storage.baz = hello world;
storage.text = she sells sea schells by the sea shore;
s = storage;
setTimeout(runlater, 10);
});
function runlater() {
s.foo = bar; // throws an exception
}
would work fine, both in workers and outside them. It would also
remove the racyness that many localStorage implementations have since
they don't implement the storage mutex.
/ Jonas
Re: [chromium-html5] LocalStorage inside Worker
On , Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jan 6, 2011 at 12:01 PM, Jeremy Orlow jor...@chromium.org wrote:
public-webapps is probably the better place for this email
On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim felix.ha...@gmail.com wrote:
I know this has been discussed 1 year ago:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14087.html
I couldn't find the follow up, so I guess localStorage is still
inaccessible from Workers?
Yes.
I have one other option aside from what mentioned by Jeremy:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14075.html
5: Why not make localStorage accessible from the Workers as read only ?
The use case is as following:
First, the user in the main window page (who has read/write access to
localStorage), dumps a big data to localStorage. Once all data has
been set, then the main page spawns Workers. These workers read the
data from localStorage, process it, and returns via message passing
(as they cannot alter the localStorage value).
What are the benefits?
1. No lock, no deadlock, no data race, fast, and efficient (see #2 below).
2. You only set the data once, read by many Worker threads (as opposed
to give the big data again and again from the main page to each of the
Workers via message).
3. It is very easy to use compared to using IndexedDB (i'm the big
proponent in localStorage).
Note: I was not following the discussion on the spec, and I don't know
if my proposal has been discussed before? or is too late to change
now?
I don't think it's too late or has had much discussion any time recently.
It's probably worth re-exploring.
Unfortunately this is not possible. Since localStorage is
synchronously accessed, if we allowed workers to access it that would
mean that we no longer have a shared-nothing-message-passing threading
model. Instead we'd have a shared memory threading model which would
require locks, mutexes, etc.
Making it readonly unfortunately doesn't help. Consider worker code like:
var x = 0;
if (localStorage.foo 10) {
x += localStorage.foo;
}
would you expect x ever being something other than 0 or 1?
Not different from two different tabs/windows running the same code. So the
same solution for that case would work for Workers.
Making the API async would make it more hard to use, which is, I believe, one
of the design goals of localStorage: to be simple.
If two consecutive reads of the same localStorage value can yield different
values, then that's something that developers have to cope with. If they do
code that is sensible to that issue, then they can take a snapshot of the
storage object, and apply it back later.
Re: [chromium-html5] LocalStorage inside Worker
On Thu, Jan 6, 2011 at 2:25 PM, João Eiras joao.ei...@gmail.com wrote:
On , Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jan 6, 2011 at 12:01 PM, Jeremy Orlow jor...@chromium.org wrote:
public-webapps is probably the better place for this email
On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim felix.ha...@gmail.com
wrote:
I know this has been discussed 1 year ago:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14087.html
I couldn't find the follow up, so I guess localStorage is still
inaccessible from Workers?
Yes.
I have one other option aside from what mentioned by Jeremy:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14075.html
5: Why not make localStorage accessible from the Workers as read only
?
The use case is as following:
First, the user in the main window page (who has read/write access to
localStorage), dumps a big data to localStorage. Once all data has
been set, then the main page spawns Workers. These workers read the
data from localStorage, process it, and returns via message passing
(as they cannot alter the localStorage value).
What are the benefits?
1. No lock, no deadlock, no data race, fast, and efficient (see #2
below).
2. You only set the data once, read by many Worker threads (as opposed
to give the big data again and again from the main page to each of the
Workers via message).
3. It is very easy to use compared to using IndexedDB (i'm the big
proponent in localStorage).
Note: I was not following the discussion on the spec, and I don't know
if my proposal has been discussed before? or is too late to change
now?
I don't think it's too late or has had much discussion any time recently.
It's probably worth re-exploring.
Unfortunately this is not possible. Since localStorage is
synchronously accessed, if we allowed workers to access it that would
mean that we no longer have a shared-nothing-message-passing threading
model. Instead we'd have a shared memory threading model which would
require locks, mutexes, etc.
Making it readonly unfortunately doesn't help. Consider worker code like:
var x = 0;
if (localStorage.foo 10) {
x += localStorage.foo;
}
would you expect x ever being something other than 0 or 1?
Not different from two different tabs/windows running the same code. So the
same solution for that case would work for Workers.
Making the API async would make it more hard to use, which is, I believe,
one of the design goals of localStorage: to be simple.
Exposing the web platform to shared memory multithreading is the exact
opposite of simple.
If two consecutive reads of the same localStorage value can yield different
values, then that's something that developers have to cope with. If they do
code that is sensible to that issue, then they can take a snapshot of the
storage object, and apply it back later.
Multithreaded shared memory programming is extremely complex.
Multithreaded shared memory programming without the use of locks is
beyond what I'd ever want to expose anyone to. Much less web
developers.
We've been down this discussion before. Please read the threads on why
workers were designed as a shared-nothing message passing model rather
than a pthreads or similar model.
/ Jonas
Re: [chromium-html5] LocalStorage inside Worker
There is always Software Transactional Memory that provides a safe model for
memory shared between threads.
http://en.wikipedia.org/wiki/Software_transactional_memory
This has been used very successfully in Haskell for overcoming threading /
state issues. Combined with Haskells Channels (message queues) it provides
for very elegant multi-threading.
Cheers,
Keean.
On 6 January 2011 22:44, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jan 6, 2011 at 2:25 PM, João Eiras joao.ei...@gmail.com wrote:
On , Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jan 6, 2011 at 12:01 PM, Jeremy Orlow jor...@chromium.org
wrote:
public-webapps is probably the better place for this email
On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim felix.ha...@gmail.com
wrote:
I know this has been discussed 1 year ago:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14087.html
I couldn't find the follow up, so I guess localStorage is still
inaccessible from Workers?
Yes.
I have one other option aside from what mentioned by Jeremy:
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14075.html
5: Why not make localStorage accessible from the Workers as read
only
?
The use case is as following:
First, the user in the main window page (who has read/write access to
localStorage), dumps a big data to localStorage. Once all data has
been set, then the main page spawns Workers. These workers read the
data from localStorage, process it, and returns via message passing
(as they cannot alter the localStorage value).
What are the benefits?
1. No lock, no deadlock, no data race, fast, and efficient (see #2
below).
2. You only set the data once, read by many Worker threads (as opposed
to give the big data again and again from the main page to each of the
Workers via message).
3. It is very easy to use compared to using IndexedDB (i'm the big
proponent in localStorage).
Note: I was not following the discussion on the spec, and I don't know
if my proposal has been discussed before? or is too late to change
now?
I don't think it's too late or has had much discussion any time
recently.
It's probably worth re-exploring.
Unfortunately this is not possible. Since localStorage is
synchronously accessed, if we allowed workers to access it that would
mean that we no longer have a shared-nothing-message-passing threading
model. Instead we'd have a shared memory threading model which would
require locks, mutexes, etc.
Making it readonly unfortunately doesn't help. Consider worker code
like:
var x = 0;
if (localStorage.foo 10) {
x += localStorage.foo;
}
would you expect x ever being something other than 0 or 1?
Not different from two different tabs/windows running the same code. So
the
same solution for that case would work for Workers.
Making the API async would make it more hard to use, which is, I believe,
one of the design goals of localStorage: to be simple.
Exposing the web platform to shared memory multithreading is the exact
opposite of simple.
If two consecutive reads of the same localStorage value can yield
different
values, then that's something that developers have to cope with. If they
do
code that is sensible to that issue, then they can take a snapshot of the
storage object, and apply it back later.
Multithreaded shared memory programming is extremely complex.
Multithreaded shared memory programming without the use of locks is
beyond what I'd ever want to expose anyone to. Much less web
developers.
We've been down this discussion before. Please read the threads on why
workers were designed as a shared-nothing message passing model rather
than a pthreads or similar model.
/ Jonas
Re: [chromium-html5] LocalStorage inside Worker
On 1/6/11 2:57 PM, Keean Schupke wrote: There is always Software Transactional Memory that provides a safe model for memory shared between threads. http://en.wikipedia.org/wiki/Software_transactional_memory On 6 January 2011 22:44, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jan 6, 2011 at 2:25 PM, João Eiras joao.ei...@gmail.com mailto:joao.ei...@gmail.com wrote: On , Jonas Sicking jo...@sicking.cc wrote: On Thu, Jan 6, 2011 at 12:01 PM, Jeremy Orlow jor...@chromium.org mailto:jor...@chromium.org wrote: On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim felix.ha...@gmail.com mailto:felix.ha...@gmail.com wrote: I know this has been discussed 1 year ago: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14087.html I couldn't find the follow up, so I guess localStorage is still inaccessible from Workers? Exposing the web platform to shared memory multithreading is the exact opposite of simple. Shouldn't sessionStorage be made accessible? I don't think localStorage should be (to web workers), but sessionStorage seems a reasonable request. -Charles
Re: [chromium-html5] LocalStorage inside Worker
On Thu, Jan 6, 2011 at 3:06 PM, Charles Pritchard ch...@jumis.com wrote: On 1/6/11 2:57 PM, Keean Schupke wrote: There is always Software Transactional Memory that provides a safe model for memory shared between threads. http://en.wikipedia.org/wiki/Software_transactional_memory On 6 January 2011 22:44, Jonas Sicking jo...@sicking.cc wrote: On Thu, Jan 6, 2011 at 2:25 PM, João Eiras joao.ei...@gmail.com wrote: On , Jonas Sicking jo...@sicking.cc wrote: On Thu, Jan 6, 2011 at 12:01 PM, Jeremy Orlow jor...@chromium.org wrote: On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim felix.ha...@gmail.com wrote: I know this has been discussed 1 year ago: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14087.html I couldn't find the follow up, so I guess localStorage is still inaccessible from Workers? Exposing the web platform to shared memory multithreading is the exact opposite of simple. Shouldn't sessionStorage be made accessible? I don't think localStorage should be (to web workers), but sessionStorage seems a reasonable request. Why wouldn't that have the same threading issues as I described? / Jonas
Re: [chromium-html5] LocalStorage inside Worker
2011/1/6 Keean Schupke ke...@fry-it.com: There is always Software Transactional Memory that provides a safe model for memory shared between threads. http://en.wikipedia.org/wiki/Software_transactional_memory This has been used very successfully in Haskell for overcoming threading / state issues. Combined with Haskells Channels (message queues) it provides for very elegant multi-threading. Can you provide a link to the Haskell API which you think has been working well for haskell. Or even better, considering that haskell is a vastly different language from javascript, could you propose a javascript API based on Software Transactional Memory. / Jonas
Re: [chromium-html5] LocalStorage inside Worker
Did you see section 7 in the link I posted? 7 Implementations 7.1 C/C++ 7.2 C# 7.3 Common Lisp 7.4 Haskell 7.5 Java 7.6 OCaml 7.7 Perl 7.8 Python 7.9 Scala 7.10 Smalltalk JavaScript as a functional language (first class functions, closures, anonymous functions) has a lot in common with Haskell and other functional languages (Lisp)... Although as you can see there are plenty of OO implementations too. Cheers, Keean. 2011/1/6 Jonas Sicking jo...@sicking.cc 2011/1/6 Keean Schupke ke...@fry-it.com: There is always Software Transactional Memory that provides a safe model for memory shared between threads. http://en.wikipedia.org/wiki/Software_transactional_memory This has been used very successfully in Haskell for overcoming threading / state issues. Combined with Haskells Channels (message queues) it provides for very elegant multi-threading. Can you provide a link to the Haskell API which you think has been working well for haskell. Or even better, considering that haskell is a vastly different language from javascript, could you propose a javascript API based on Software Transactional Memory. / Jonas
Re: [chromium-html5] LocalStorage inside Worker
Here's a link to some papers on STM: http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/ A simple example: http://www.haskell.org/haskellwiki/Simple_STM_example Here's a tutorial: http://book.realworldhaskell.org/read/software-transactional-memory.html Here's a link to the docs: http://hackage.haskell.org/package/stm Cheers, Keean. 2011/1/6 Keean Schupke ke...@fry-it.com Did you see section 7 in the link I posted? 7 Implementations 7.1 C/C++ 7.2 C# 7.3 Common Lisp 7.4 Haskell 7.5 Java 7.6 OCaml 7.7 Perl 7.8 Python 7.9 Scala 7.10 Smalltalk JavaScript as a functional language (first class functions, closures, anonymous functions) has a lot in common with Haskell and other functional languages (Lisp)... Although as you can see there are plenty of OO implementations too. Cheers, Keean. 2011/1/6 Jonas Sicking jo...@sicking.cc 2011/1/6 Keean Schupke ke...@fry-it.com: There is always Software Transactional Memory that provides a safe model for memory shared between threads. http://en.wikipedia.org/wiki/Software_transactional_memory This has been used very successfully in Haskell for overcoming threading / state issues. Combined with Haskells Channels (message queues) it provides for very elegant multi-threading. Can you provide a link to the Haskell API which you think has been working well for haskell. Or even better, considering that haskell is a vastly different language from javascript, could you propose a javascript API based on Software Transactional Memory. / Jonas
Re: [chromium-html5] LocalStorage inside Worker
On Thu, Jan 6, 2011 at 5:11 PM, Jonas Sicking jo...@sicking.cc wrote:
Unfortunately this is not possible. Since localStorage is
synchronously accessed, if we allowed workers to access it that would
mean that we no longer have a shared-nothing-message-passing threading
model. Instead we'd have a shared memory threading model which would
require locks, mutexes, etc.
This already exists, when multiple instances of a page access
localStorage. I don't see how workers are any different.
I'm aware that this is technically a bug, since it ignores the storage
mutex required by the spec--but it doesn't seem like browsers have any
intention of implementing that. It seems like the spec should
describe something that will actually be implemented in browsers. In
the end, it seems like the real-world implementations of localStorage
lose nothing by allowing workers access to it; it's only a loss for
the theoretical version in the spec that nobody is implementing.
Unless vendors have changed their mind on the mutex and are starting
to implement it, anyway.
That said. As I have suggested before (don't remember if it was here
or on the whatwg list), if we create a new version of localStorage,
where you can only get a reference to the localStorage object
asynchronously, then we should be fine. So something like:
var s;
getBetterStorage(function(storage) {
storage.foo += storage.bar;
storage.baz = hello world;
storage.text = she sells sea schells by the sea shore;
s = storage;
setTimeout(runlater, 10);
});
function runlater() {
s.foo = bar; // throws an exception
}
would work fine, both in workers and outside them. It would also
remove the racyness that many localStorage implementations have since
they don't implement the storage mutex.
This would require that only one async storage callback (for a
particular Storage object) can be running at any one time. That means
browsers would have to lock the storage object to prevent that--and
that's essentially the same as the current mutex requirement. In
other words, I suspect browsers wouldn't implement it.
--
Glenn Maynard
Re: [chromium-html5] LocalStorage inside Worker
On Thu, Jan 6, 2011 at 3:47 PM, Glenn Maynard gl...@zewt.org wrote:
That said. As I have suggested before (don't remember if it was here
or on the whatwg list), if we create a new version of localStorage,
where you can only get a reference to the localStorage object
asynchronously, then we should be fine. So something like:
var s;
getBetterStorage(function(storage) {
storage.foo += storage.bar;
storage.baz = hello world;
storage.text = she sells sea schells by the sea shore;
s = storage;
setTimeout(runlater, 10);
});
function runlater() {
s.foo = bar; // throws an exception
}
would work fine, both in workers and outside them. It would also
remove the racyness that many localStorage implementations have since
they don't implement the storage mutex.
This would require that only one async storage callback (for a
particular Storage object) can be running at any one time. That means
browsers would have to lock the storage object to prevent that--and
that's essentially the same as the current mutex requirement. In
other words, I suspect browsers wouldn't implement it.
No, implementing the storage mutex is an orders of magnitude harder
than implementing a locking mechanism prevents the callback from
happening in multiple threads at the same time. I'm saying that with
my implementor hat on. They are two very different types of locks. A
major difference is that one is grabbed synchronously and the other
asynchronously.
/ Jonas
Re: [chromium-html5] LocalStorage inside Worker
Applying this to JavaScript (ignoring local storage and just implementing an
STM) would come up with something like:
1) Objects from one thread should not be visible to another. Global variable
test defined in the UI or any worker thread should no be in scope in any
other worker-thread.
2) shared objects could be accessed only though the atomic method
(implemented natively).
atomic(function(shared) {
shared.x += 1;
shared.y -= 2;
});
Here, the callback is the transaction, and shared is the shared
namespace... Thats all you need for a basic implementation. The clever stuff
is all hidden from the user.
We could implement retry by returning true... the guard could just be a
boolean function too:
atomic(function(shared) {
if (queueSize 0) {
// remove item from queue and use it
return false; // no retry
} else {
return true; // retry
}
});
Thats pretty much the entire user visible API that would be needed. Of
course the implementation behind the scenes is more complex.
Cheers,
Keean.
2011/1/6 Keean Schupke ke...@fry-it.com
Here's a link to some papers on STM:
http://research.microsoft.com/en-us/um/people/simonpj/papers/stm/
A simple example:
http://www.haskell.org/haskellwiki/Simple_STM_example
Here's a tutorial:
http://book.realworldhaskell.org/read/software-transactional-memory.html
Here's a link to the docs:
http://hackage.haskell.org/package/stm
Cheers,
Keean.
2011/1/6 Keean Schupke ke...@fry-it.com
Did you see section 7 in the link I posted?
7 Implementations
7.1 C/C++
7.2 C#
7.3 Common Lisp
7.4 Haskell
7.5 Java
7.6 OCaml
7.7 Perl
7.8 Python
7.9 Scala
7.10 Smalltalk
JavaScript as a functional language (first class functions, closures,
anonymous functions) has a lot in common with Haskell and other functional
languages (Lisp)... Although as you can see there are plenty of OO
implementations too.
Cheers,
Keean.
2011/1/6 Jonas Sicking jo...@sicking.cc
2011/1/6 Keean Schupke ke...@fry-it.com:
There is always Software Transactional Memory that provides a safe
model for
memory shared between threads.
http://en.wikipedia.org/wiki/Software_transactional_memory
This has been used very successfully in Haskell for overcoming
threading /
state issues. Combined with Haskells Channels (message queues) it
provides
for very elegant multi-threading.
Can you provide a link to the Haskell API which you think has been
working well for haskell. Or even better, considering that haskell is
a vastly different language from javascript, could you propose a
javascript API based on Software Transactional Memory.
/ Jonas
Re: [chromium-html5] LocalStorage inside Worker
On Thu, Jan 6, 2011 at 6:06 PM, Charles Pritchard ch...@jumis.com wrote: Shouldn't sessionStorage be made accessible? I don't think localStorage should be (to web workers), but sessionStorage seems a reasonable request. Why? I've wanted to access localStorage from workers in the past, and if the details for accessing Storage objects are worked out at all, then exposing sessionStorage but not localStorage seems arbitrary and unnecessarily restrictive. -- Glenn Maynard
Re: [chromium-html5] LocalStorage inside Worker
2011/1/6 Keean Schupke ke...@fry-it.com:
Applying this to JavaScript (ignoring local storage and just implementing an
STM) would come up with something like:
1) Objects from one thread should not be visible to another. Global variable
test defined in the UI or any worker thread should no be in scope in any
other worker-thread.
2) shared objects could be accessed only though the atomic method
(implemented natively).
atomic(function(shared) {
shared.x += 1;
shared.y -= 2;
});
Here, the callback is the transaction, and shared is the shared
namespace... Thats all you need for a basic implementation. The clever stuff
is all hidden from the user.
We could implement retry by returning true... the guard could just be a
boolean function too:
atomic(function(shared) {
if (queueSize 0) {
// remove item from queue and use it
return false; // no retry
} else {
return true; // retry
}
});
Thats pretty much the entire user visible API that would be needed. Of
course the implementation behind the scenes is more complex.
This looks basically like what I proposed with getBetterStoreage
renamed to atomic.
But I'm guessing that it's also intended that atomic is synchronous
whereas getBetterStoreage was asynchronous. I think that would be fine
in workers, but it'd have many of the same complications as the
storage mutex if implemented for the main thread.
/ Jonas
Re: [chromium-html5] LocalStorage inside Worker
On Thu, Jan 6, 2011 at 7:11 PM, Jonas Sicking jo...@sicking.cc wrote: No, implementing the storage mutex is an orders of magnitude harder than implementing a locking mechanism prevents the callback from happening in multiple threads at the same time. I'm saying that with my implementor hat on. They are two very different types of locks. A major difference is that one is grabbed synchronously and the other asynchronously. Either way, if it satisfies the goal of having a strictly-correct spec and is enough to unblock access to Storage from workers, I'm fine with that (whether or not the locking is reliably implemented in practice). -- Glenn Maynard
Re: [chromium-html5] LocalStorage inside Worker
On 1/6/11 5:25 PM, João Eiras wrote: Not different from two different tabs/windows running the same code. In which current browsers do same-origin tabs/windows end up interleaving their JS (that is, one runs JS before the other has returned to the event loop)? -Boris
