I don't know of a reason we need more than 1 history thread, but I can't say for sure. HistoryService is responsible today for starting/stopping/destroying the history thread, so if we have multiple services then we need to be smarter about that... Anyone opposed to moving history_thread to BrowserProcess and mimic what is done for the other threads? HistoryService::Cleanup does some fancy footwork and ultimately joins on it's thread, but afaict it doesn't need to [join]. I can think of other options but they feel much less cool, like saying that the default profile's history service manges the history thread, or having a refcountable HistoryThread type, ...
On Sat, Apr 11, 2009 at 3:51 PM, Adam Barth <[email protected]> wrote: > Oops. Wrong address. See below: > > On Sat, Apr 11, 2009 at 3:47 PM, Adam Barth <abarth@> wrote: > > That sound fine. The other option is to make the history thread not > > well-known (i.e., take away its ChromeThread::HISTORY name). Is there > > a reason to have N history threads with N profiles? > > > > Adam > > > > > > On Sat, Apr 11, 2009 at 3:02 PM, Tim Steele <[email protected]> wrote: > >> I promise I'm not back to my antics of suggesting we stick to the "one > >> profile per process" model, but I hit a little snag trying to write a > test > >> where I want to create a different profile. I'm wondering what I'm > doing > >> wrong / how this was originally intended to work in the "multiple > profile > >> per process" world... willing to fix things if need be. It's an > >> InProcessBrowserTest, so I've got a standard Browser object already up > and > >> running with the Default profile for the test user data directory. I > then > >> use ProfileManager to CreateProfile; so far so good. As soon as you try > and > >> do anything with this profile that touches HistoryService (for example), > we > >> choke because the lazy-initializer for the second profile's > HistoryService > >> wants to create a ChromeThread::HISTORY, which already exists. This is > >> something we don't hit with incognito because it reuses the same > service, > >> but I think a long, long time ago when we had some notion of true > >> multi-profile support this must have worked. I assume the original > intent > >> was to re-use the same history thread for multiple profiles. Not sure > how > >> to make that work at the moment, ChromeThread is pretty tight-lipped > from an > >> API standpoint. Naively it feels like we could just > >> check-if-exists-and-reuse-else-create in this case. Is that sane? > >> Tim > >> > >> > >> > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
