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
-~----------~----~----~----~------~----~------~--~---
