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 <t...@chromium.org> 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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
