On Wed, Sep 16, 2009 at 1:06 PM, James Robinson <span dir="ltr"><<a href="mailto:jamesr@google.com">jamesr@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im">On Wed, Sep 16, 2009 at 11:34 AM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com" target="_blank">michaeln@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Wed, Sep 16, 2009 at 11:24 AM, James Robinson <span dir="ltr"><<a href="mailto:jamesr@google.com" target="_blank">jamesr@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>On Wed, Sep 16, 2009 at 10:53 AM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com" target="_blank">michaeln@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Wed, Sep 16, 2009 at 9:58 AM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jeremy, what's the use case here - do developers want workers to have access to shared local storage with pages? Or do they just want workers to have access to their own non-shared local storage?<div><br></div><div>Because we could just give workers their own separate WorkerLocalStorage and let them have at it. A worker could block all the other accesses to WorkerLocalStorage within that domain, but so be it - it wouldn't affect page access, and we already had that issue with the (now removed?) synchronous SQL API.<br>
<br></div><div>I think a much better case can be made for WorkerLocalStorage than for "give workers access to page LocalStorage", and the design issues are much simpler.</div></blockquote><div><br></div></div><div>
Putting workers in their own storage silo doesn't really make much sense? Sure it may be simpler for browser vendors, but does that make life simpler for app developers, or just have them scratching their heads about how to read/write the same data set from either flavor of context in their application?</div>
<div><br></div><div>I see no rhyme or reason for the arbitrary barrier except for browser vendors to work around the awkward implict locks on LocalStorage (the source of much grief). Consider this... would it make sense to cordon off the databases workers vs pages can see? I would think not, and i would hope others agree.</div>
</div></blockquote><div><br></div></div><div>The difference is that the database interface is purely asynchronous whereas storage is synchronous.</div></div></blockquote><div><br></div></div><div>Sure... we're talking about adding an async api that allows worker to access a local storage repository... should such a thing exist, why should it not provide access to the same repository as seen by pages?</div>
</div></blockquote><div><br></div></div><div>Not quite - Jeremy proposed giving workers access to a synchronous API (localStorage.*) but to only allow it to be called within the context of a callback that the UA can run when it chooses. It's another way to approach the implicit locking since a UA would have to, in effect, hold the storage mutex for the duration of the callback. The page's context could still be blocked for an indefinite amount of time by a worker thread.</div>
</div></blockquote><div><br></div><div>Exactly. And I acknowledged this in my original email.</div><div><br></div><div>Unfortunately, I don't have a good solution to the problem. The only thing I can think of is some timeout, but these would be inherently racy. There are times when the system is under heavy load and _everything_ goes slower. I don't see how we could enforce that workers don't keep LocalStorage locked for long enough that UI threads become affected and still keep behavior deterministic from the web developers point of view.</div>
<div><br></div><div>That said, IF (and this is a big if) we decide to make localStorage NOT have any run to completion semantics across event loops and instead add in an async interface for atomic access to localStorage, then this would work, however.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>Drew suggested isolating the worker's access to a separate storage 'arena' so that there wouldn't be shared, synchronous access between the page context and a worker context. This way the synchronous Storage API can be used essentially unchanged without having to deal with the more nasty parts of synchronization.</div>
</div></blockquote><div><br></div><div>Drew, the most important thing to the developers I talked to is that they need _some_ storage directly accessible to workers. Many were thinking in terms of a shared worker syncing and doing the bulk of the processing and then one or more pages acting as thin clients. Some of them wanted to use it like shared memory (i.e. workers syncing and doing some processing and then storing information in storage; pages then display based on that data). This is especially interesting because storage events can be used to trigger updates to content.</div>
<div><br></div><div>As I think about it, I suppose most of the use cases could actually be solved by a storage for workers, whether or not pages can also access it. If the burden were low, it would be nice to make them accessible though. If we did this, keeping some form of storage events would be nice.</div>
<div><br></div><div>Note that most of the developers I talked to thought LocalStorage was not powerful enough for their needs, but since it's the only API supported by all the browsers they figured they were stuck with it, so they'd have to find _some_ way to make it work.</div>
<div><br></div><div>So....maybe it doesn't make sense to spend a lot of effort making LocalStorage (in some form or another) work in workers. Maybe we should instead put our effort into something like WebSimpleDatabase?</div>
<div><br></div><div>J</div></div>