On Tue, Nov 3, 2009 at 12:03 AM, Paweł Hajdan Jr.
<phajdan...@chromium.org>wrote:

> On Tue, Nov 3, 2009 at 06:50, John Abd-El-Malek <j...@chromium.org> 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)?
>

Sure, look at BufferedResourceHandler or ResourceMessageFilter, which both
need to load plugins on the file 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.
>

Great, I missed that one since I was just looking for caching of MessageLoop
pointers.  Thanks.

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to