W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] localStorage + worker processes

From: Jeremy Orlow <jorlow@google.com>
Date: Mon, 23 Mar 2009 16:42:56 -0700
Message-ID: <5dd9e5c50903231642i1e302d78p2c802df8273495d0@mail.gmail.com>
*Given that things have simmered down, it seems like it's time for a re-cap
of the options.  I believe this includes all the options currently on the
table (in broad strokes anyhow).  If I missed anything or grossly
mischaracterized any idea, feel free to correct me.*
0:  Do nothing.  As far as I can tell, no one thinks this is a valid option.
1:  Simply disallow localStorage in workers.  Possibly allow in
shared/persistent workers, but give them their own private storage area.
2:  Explicit locking.  Possibly only required for workers.  Would require
dead lock detection or for the spec to dictate locking precedence if another
lock were introduced.
3:  Expose localStorage to workers as asynchronous calls.  Most similar to
other concurrency solutions within workers.
4:  Have some yield/checkpoint/commit type call on localStorage that would
release any implicit/invisible lock.  This could also be useful in
conjunction with #3.


*My opinion:*
#1 would definitely work, but doesn't seem necessary.  #2 seems to go
against the grain of how concurrency is implemented everywhere else in the
spec.  In addition, it could open pandora's box in terms of locks being
added in elsewhere and starting to cause some messy issues there.  #3 and #4
preserve the simplicity of localStorage for the simple/common case--which is
important above else, in my opinion.



On Mon, Mar 23, 2009 at 2:48 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Tue, Mar 24, 2009 at 10:40 AM, Jeremy Orlow <jorlow at google.com> wrote:
>
>> I really like the idea of some generic yield, though I wonder if there's
>> some reason it hasn't been added earlier.  People have been using the
>> setTimeout(..., 0) trick for a while to get around slow script warnings (and
>> general unresponsiveness)...so surely something like this must have come up
>> before?  If so, what were the drawbacks?
>>
>
> An obvious issue is that you can easily end up with arbitrarily deep
> nesting and stack overflows.
>
> Rob
> --
> "He was pierced for our transgressions, he was crushed for our iniquities;
> the punishment that brought us peace was upon him, and by his wounds we are
> healed. We all, like sheep, have gone astray, each of us has turned to his
> own way; and the LORD has laid on him the iniquity of us all." [Isaiah
> 53:5-6]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090323/109764cb/attachment-0001.htm>
Received on Monday, 23 March 2009 16:42:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT