On Tue, Oct 6, 2009 at 5:30 PM, Peter Kasting <pkast...@google.com> wrote:
> On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek <j...@chromium.org>wrote:
>
>> Given that sqlite corruption means (repeated) crashing of the browser
>> process, it seems this data heavily suggests we should separate sqlite code
>> into a separate process.
>>
>
> What does this mean for cases like the in-memory URL database, which is
> sqlite code running on a completely in-memory dataset? This is currently
> used synchronously inside the UI threas to do things like inline
> autocomplete. We _cannot_ make it async or move it to another thread.
>
> So are you proposing to move _some_ sqlite accesses elsewhere?
>
I'm not sure, I think this is one of the questions that needs to be explored
more by whoever investigates this.
If corruption in the in-memory URL database doesn't survive a crash (i.e.
because it's recreated each time), then perhaps it's ok to keep it in the
browser process. However, if it's not, I'm not sure I understand why moving
it to another process is unworkable? Chrome code is littered with many
examples of how we turned synchronous operations into asynchronous ones.
But if worst comes to worst and we can't, you can always do sync IPC calls
to another process. The overhead is in the microseconds so it won't
be noticeable.
>
> (Personally, I don't think this paper is evidence that we should move
> sqlite into a separate process, for similar reasons as to Scott.)
>
> PK
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
