- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 11 Jan 2011 18:06:44 -0500
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Jeremy Orlow <jorlow@chromium.org>, Keean Schupke <keean@fry-it.com>, robert@ocallahan.org, Charles Pritchard <chuck@jumis.com>, public-webapps WG <public-webapps@w3.org>
On Tue, Jan 11, 2011 at 3:58 PM, Jonas Sicking <jonas@sicking.cc> wrote: > With localStorage being the way it is, I personally don't think we can > ever allow localStorage access in workers. This makes sense if the storage mutex goes away entirely for localStorage itself (reflecting current implementations). If localStorage retains the current unimplemented locking, then it makes sense to use the same Storage for both APIs. The async callback would use the same storage mutex, so a fully compliant implementation would be threadsafe. Removing it makes sense to me, though. > 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); I guess to determine whether a particular named storage is supported, you'd call it with the name and an empty callback; if the name isn't supported, it raises an exception. A little awkward, but reasonable. Maybe the specs guarantee this in general for async callbacks, but getNamedStorage should never run callback immediately before returning, even if the lock is available; always wait for the script to return, as if the lock was taken. > 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. StorageEvent would need an additional attribute, containing the name associated with the storageArea it's been given. That's because you can no longer say eg. "event.storageArea == window.localStorage" to determine which Storage triggered the event. Other than that, the storage event is straightforward; when called during a storage callback, it has access to the locked Storage object via storageArea. > Also, you're not allowed to nest getNamedStorageSync and/or > IDBDatabaseSync.transaction calls. If a single mutex is used for all storage objects, then nesting getNamedStorageSync with itself is safe. If separate mutexes are used for each storage object, then it's still okay to nest getNamedStorageSync calls to the same object. This essentially makes it act like a recursive mutex, which can be very convenient. It reduces how much a function has to care about its caller; your Javascript function doesn't need to specify "must not be called from a getNamedStorageSync callback" if it uses that function itself. One other thing to consider: releasing the Storage object and continuing execution. The minimum delays imposed on timers makes setTimeout(continueFunction, 0) a poor solution. On Tue, Jan 11, 2011 at 5:11 PM, Keean Schupke <keean@fry-it.com> wrote: > Would each 'name' storage have its own thread to improve parallelism? Callbacks would execute in the thread they were queued from, not in a separate thread, if that's what you mean. -- Glenn Maynard
Received on Tuesday, 11 January 2011 23:07:15 UTC