[chromium-dev] Re: question on profiles ChromeThread
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 aba...@chromium.org 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 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: question on profiles ChromeThread
On Mon, Apr 13, 2009 at 11:01 AM, Tim Steele t...@chromium.org wrote: 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, ... We need the UI thread to Join with the history thread to ensure that all the data is written. If it doesn't join, the history thread will be force-terminated when the UI thread exits. However, the BrowserProcess destructor should do this join for you when it deletes the thread. I don't think there's any reason other than completeness that the history thread needs a name, so just removing that is the easiest thing. As you can see, history shutdown is tricky. But I don't have an objection if you want to move it to BrowserProcess, either, as long as you fix any problems that arise :) Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: question on profiles ChromeThread
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 -~--~~~~--~~--~--~---
