- From: Michael Nordman <michaeln@google.com>
- Date: Mon, 23 Mar 2009 11:46:56 -0700
On Mon, Mar 23, 2009 at 11:41 AM, Jeremy Orlow <jorlow at google.com> wrote: > One thing that hasn't been considered yet is some sort of optional hint to > say "I'm done" in terms of accessing localStorage. Maybe call it > localStorage.checkpoint() or localStroage.commit()? > > As far as the browser implemenation is concerned, a call to this function > would be the same as the script ending. The great thing about this is that > if a developer found one problem location in their code, they could add > it--but it'd be completely optional. > > This could be used in conjunction with most of the other ideas already > floating around. > If we're stuck with the "implicit" lock (somewhat insidious in my "radical" view:), agree an explicit means of releasing that lock would be nice.... .Unlock() maybe? > > J > > > On Sun, Mar 22, 2009 at 4:24 PM, Drew Wilson <atwilson at google.com> wrote: > >> If you deny workers, you can enforce exclusive access to localStorage by >> applying a lock that extends from the first access of localStorage until the >> script re-enters the event loop. Page script is guaranteed to re-enter the >> event loop fairly quickly (lest it trigger the browser's "this script is >> taking too long to run" protection) so you won't get starvation. Since >> worker script never has to re-enter the event loop, this isn't a feasible >> solution for workers. >> >> That's why I'm proposing that the most reasonable implementation is just >> to have a simple lock like I describe above, and then either deny access to >> localStorage to dedicated workers (shared workers can silo the storage as I >> described previously), or else just enforce a limit to how long workers can >> hold the localStorage lock (if they hold it beyond some period, they get >> terminated just like page script that doesn't re-enter the event loop). >> >> -atw >> >> On Sun, Mar 22, 2009 at 12:07 PM, Michael Nordman <michaeln at google.com>wrote: >> >>> >>> I don't see how denying workers solves the problem. In a multi-threaded >>> browser, this has to be resolved reasonably even in the absence of workers. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090323/b2bb8e5f/attachment.htm>
Received on Monday, 23 March 2009 11:46:56 UTC