Everything without a comment has been incorporated into the doc.
On Tue, Apr 14, 2009 at 9:36 AM, Darin Fisher <da...@chromium.org> wrote:
> LocalStorage
>
> "Luckily, each origin is completely isolated from the next, so we
> essentially must implement a per-origin lock for localStorage." <-- In
> discussing this with Ian Hickson, he was convinced that we would still need
> a global lock to avoid dead-locks. I didn't fully understand the dead-lock
> scenario he was concerned about, so it might be good to ask him about it.
> He said you could imagine a frame from origin A containing a frame from
> origin B. There may also be a frame from origin B containing a frame from
> origin A in another process. If there was a way for script in the outer
> frame to synchronously block on execution of script in the inner frame, then
> I guess you could get a dead-lock. I'm not sure how to construct that
> scenario though. I'm probably overlooking something...
>
This is interesting. Off the top of my head, I think the policy of
releasing the lock whenever we do anything synchronous is enough to protect
us from this, but there might be some complicated scenarios that could blow
up. I'll email hixie (cc whatwg) asking if anyone still sees any potential
issues.
> "When a render process asks to subscribe to storage events, that process
> will be added to the set for a particular origin." <-- it seems like this
> registration will happen asynchronously in chrome. there could be some
> interesting race conditions that cause you to either send a notification
> when one was not expected or miss a notification that would be sent by
> safari. what are your plans for this? maybe the races don't matter since
> it is hard to predict (even in a single threaded browser like safari) when
> another window will modify localStorage.
>
Yeah...I considered this and almost decided that races like this don't
matter. In the end, it seemed like a small amount of extra work and latency
(how often do you register/unregister an event handler?) to handle it race
free. If this turns out to be incorrect, I'll probably switch it to async.
> It seems unfortunate to me that the spec requires a storage event to carry
> a copy of the old and new values. Oh well :(
>
Really? I think the window proxy portion is more unfortunate.
> "Other blocking operations like synchronous XHR operations and calling
> alert() should release the lock as well." <-- you should probably try to
> recognize these cases in chrome/renderer/ so that you can have a single IPC
> for unlocking.
>
I don't really understand what you mean by this. I assumed I'd just have
multiple locations that send an async unlock message. Is that not going to
work?
> StorageEvent: "These messages are synchronous and thus require a nested
> message loop." <-- why do they need to be synchronous? OK, I see that you
> are addressing the race issue I mentioned before. I think we can probably
> stick with asynchronous messages but keep a corresponding data structure in
> the renderer that allows us to drop notifications that we should not
> dispatch. i don't think we benefit from using synchronous IPC here.
>
To be honest, if we don't handle this correctly, I think there will be a
couple development teams pulling their hair out. Yeah, this will affect
0.01% of developers, but maybe we should at least try to do this
"correctly"?
> "When you fire an event, will other windows see it? If not, no need for
> the rest of this... When the event is dispatched, a synchronous message
> will be sent to the browser process which will be redistributed to all
> render processes currently subscribed. A nested message loop will be run
> during the synchronous action. (Also synchronous for serialization
> purposes.)" <-- I don't understand this. Since storage events originate in
> the browser, why would the renderer need to send them back to the browser to
> be re-distributed?
>
This was talking about DocumentEvent.createEvent which happens in v8 in a
render process. The only question (and this is something I can answer by
myself--I just haven't yet) is whether events created in one window are
supposed to be transmitted to all other windows in that origin. I'd assume
yes.
> "Cleanup of WebKit's *Storage code" <-- It would be good to start the
> conversation early with folks from WebKit about how significantly different
> our implementation of localStorage is. You should expect push-back unless
> you can adequately justify why a separate implementation is required. I
> think your design is the right approach, so this should be an "easy"
> argument to make ;-)
>
Yup. My next step is starting this conversation with the WebKit people.
> "Rejected alternative approaches" <-- i'm surprised that you don't explain
> why you are not using the current webkit implementation perhaps with the
> same VFS approach that we are using for HTML5 database. the only thing
> missing there is a solution for storage events.
>
The information was there, but poorly organized. I've fleshed things out
further and re-labeled things a bit. It's not exactly easy to read because
there's many possible ways you could re-use WebKit code and there's
basically a linear relationship between how bad the solution is and how much
it reuses code.
Let me know if I missed anything in my analysis.
> the costs to having a separate implementation from apple is non-trivial.
> ideally you're solution here would be a refactoring of their code to enable
> you to share some of their code. for example, i would expect that you could
> share the code that interacts with sqlite.
>
Because we're handling database operations in the browser process and we
don't use WebKit there, this is not possible.
I promise I did put a good deal of thought into how we could share more
code. My email to WebKit.org will be soliciting ideas, but I think we've
come up with pretty sound problems for each implementation. Their
implementation is _very_ rooted in the idea of having one process.
> SessionStorage
>
> I like the idea of sharing code with LocalStorage here. I think we cannot
> easily reuse the WebKit code because we need SessionStorage to be
> transferred between renderer processes: a single tab could use multiple
> renderer processes as navigations to new sites issued from the omnibox
> result in a process switch.
>
> If you use the same code as LocalStorage, you would just need to use an
> in-memory sqlite db, and have a different way of grouping the databases.
> The big downside to this approach in my mind is performance. Now you have
> to go all the way to the browser process to access sessionStorage. Safari's
> implementation will always be faster :(
>
> If we try to keep sessionStorage in webkit, then we need to have a way to
> copy it out. That may actually be required if we want to support persisting
> sessionStorage for the purposes of session restore. Hmm...
>
Yup...no obvious answers here. :-)
That said, I anticipate things being more clear once LocalStorage is done.
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
