Get rid of a dependency on MessageLoop::DestructionObserver....

Get rid of a dependency on MessageLoop::DestructionObserver.

BUG=none
TEST=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=66191

[willchan no longer on Chromium, 2010-11-04 09:51:51]

As long as you're sure that the destruction ordering is correct in the
IOThread::CleanUp() function, as I don't understand the objects well enough to
judge that, then this looks perfect to me.  Thank you!

LGTM.

[michaeln, 2010-11-04 20:16:52]

It does look odd to me that the cleanup ordering is not the inverse of the init
ordering, although the test bots are happy with the same ordering. I had
considered calling the cleanup methods in the inverse order.

How about I 'try' it with inverse ordering and see what the results are so the
next person to trip thru this code doesn't wonder about that.

I suspect the objects being cleaned up are independent (enough) from one another
and the ordering actually doesn't matter.

[willchan no longer on Chromium, 2010-11-05 09:04:49]

Ok, trying it in inverse order makes sense to me.  Thanks!

On Thu, Nov 4, 2010 at 8:16 PM, <michaeln@chromium.org> wrote:

> It does look odd to me that the cleanup ordering is not the inverse of the
> init
> ordering, although the test bots are happy with the same ordering. I had
> considered calling the cleanup methods in the inverse order.
>
> How about I 'try' it with inverse ordering and see what the results are so
> the
> next person to trip thru this code doesn't wonder about that.
>
> I suspect the objects being cleaned up are independent (enough) from one
> another
> and the ordering actually doesn't matter.
>
>
> http://codereview.chromium.org/4303003/show
>

[michaeln, 2010-11-11 23:49:58]

I've been hesitant to commit this change due to redness in the try results, the
top level results are green, but underneath things are red.

The last snapshot effectively reverts the changes in the previous snapshot (so
no material changes in this snapshot from trunk). The try results for that no-op
change show the same underlying redness.

Hmmm... I'll commit it (with real changes restored) and see what happens.