On Tue, Nov 3, 2009 at 06:50, John Abd-El-Malek <[email protected]> wrote:
> *The solution* > 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask, > DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed > if the target thread is known to outlive the current thread. The four > static methods have the same signature as the ones from MessageLoop, with > the addition of the first parameter to indicate the target thread. > > ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task); > > 3: If your object must be destructed on a specific thread, use a trait from > ChromeThread: > > class Foo : public base::RefCountedThreadSafe<Foo, > ChromeThread::DeleteOnIOThread> > Awesome! > 4: I've removed all the special casing and always made the objects in the > browser code behave in one way. If you're writing a unit test and need to > use an object that goes to a file thread (where before it would proceed > synchronously), you just need: > > ChromeThread file_thread(ChromeThread::FILE, MessageLoop::current()); > foo->StartAsyncTaskOnFileThread(); > MessageLoop::current()->RunAllPending(); > > There are plenty of examples now in the tests. > Are there any examples for asynchronous processing (with a real backend thread)? I think that chrome/browser/privacy_blacklist/blacklist_manager.cc uses some of the anti-patterns you described (it caches base::Thread* instead of MessageLoop*, but I understand it's equally bad). And it will benefit a lot from ChromeThread::DeleteOnIOThread. The good part is that BlacklistManager is not yet used in the browser. I will fix the issues before the final integration of BlacklistManager. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
