Add the ability for objects which derive from RefCountedThreadSafe to specify...

Add the ability for objects which derive from RefCountedThreadSafe to specify a destructor trait.  This allows browser objects to specify which thread they're terminated on.  The benefit is we avoid the need to do manual ref counting when an object posts tasks to itself on different threads, if an object must be destructed on a specific thread.

This patch adds initial support and only shows one example with ResourceMessageFilter.  I will do the rest in a follow-up patch to keep things small.

BUG=25354
TEST=added unit tests
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=30688

[darin (slow to review), 2009-10-30 19:57:59]

LGTM!

http://codereview.chromium.org/338065/diff/9052/9069
File chrome/browser/chrome_thread.h (right):

http://codereview.chromium.org/338065/diff/9052/9069#newcode142
Line 142: DeleteSoon(thread, FROM_HERE, x);
unfortunately, the value of FROM_HERE is a bit lost as a result of this (many
consumers all would have the same value for FROM_HERE), but i can't think of any
nice way to deal with that.

http://codereview.chromium.org/338065/diff/9052/9068
File chrome/browser/in_process_webkit/dom_storage_dispatcher_host.h (right):

http://codereview.chromium.org/338065/diff/9052/9068#newcode50
Line 50: friend struct
if we make DefaultRefCountedThreadSafeTraits call back to a static function on
RefCountedThreadSafe that then does the delete call, then we can avoid changing
these friend declarations.

http://codereview.chromium.org/338065/diff/9052/9071
File chrome/browser/renderer_host/resource_message_filter.cc (right):

http://codereview.chromium.org/338065/diff/9052/9071#newcode410
Line 410: ChromeThread::DeleteOnIOThread::Destruct(this);
nit: might be nice to use the more explicit:

  ChromeThread::DeleteSoon(ChromeThread::IO, FROM_HERE, this);

[jam, 2009-10-30 23:08:50]

http://codereview.chromium.org/338065/diff/9052/9068
File chrome/browser/in_process_webkit/dom_storage_dispatcher_host.h (right):

http://codereview.chromium.org/338065/diff/9052/9068#newcode50
Line 50: friend struct
On 2009/10/30 19:57:59, darin wrote:
> if we make DefaultRefCountedThreadSafeTraits call back to a static function on
> RefCountedThreadSafe that then does the delete call, then we can avoid
changing
> these friend declarations.

Done.

http://codereview.chromium.org/338065/diff/9052/9071
File chrome/browser/renderer_host/resource_message_filter.cc (right):

http://codereview.chromium.org/338065/diff/9052/9071#newcode410
Line 410: ChromeThread::DeleteOnIOThread::Destruct(this);
On 2009/10/30 19:57:59, darin wrote:
> nit: might be nice to use the more explicit:
> 
>   ChromeThread::DeleteSoon(ChromeThread::IO, FROM_HERE, this);

That would change the semantics a bit, since before the RMF would get deleted
right away if it's on the correct thread, but doing DeleteSoon would delay it
until the stack unwinds.  This could result in holding on to resources or memory
leaks in valgrind.