On Tue, Oct 6, 2009 at 5:56 PM, Peter Kasting <[email protected]> wrote:
> On Tue, Oct 6, 2009 at 5:53 PM, John Abd-El-Malek <[email protected]>wrote: > >> If corruption in the in-memory URL database doesn't survive a crash (i.e. >> because it's recreated each time), >> > > It doesn't > > 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. >> > > The user-visible behavior cannot be async. Inline autocomplete must never > race the user's action or it goes from awesome to hellishly annoying and > awful. > > 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. >> > > I'd far prefer to keep it in the UI thread even if it were subject to these > corruption issues. Doing sync IPC from the UI thread to a sqlite thread > sounds like a recipe for Jank. > Note, I don't know what the right answer for this specific case (I think more investigation is necessary), but I do want to point out that I don't think moving it to another process will introduce jank. If it's currently not done on the same thread as other databases, then if it were moved to another process, it would have to be done on a separate thread as well. Our overhead for sync IPCs is in the microseconds. Of course, actually implementing this and comparing histograms of in-process and out-of-process delays is the fool-proof way of proving this :) > > PK > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
