Allocate SocketController lazily.

Allocate SocketController lazily.

To work around some unit tests that use ExtensionService but don't
provide an IO thread that SocketController now needs to completely
tear itself down, we allocate SocketController lazily and DCHECK on
destruction that there is an IO thread message loop. This is a
reasonable compromise for getting the benefit of lifetime management
by sticking SocketController in ExtensionService.

BTW, aa said putting random crap in ExtensionService wasn't a good idea.
Our chickens are coming home to roost. As platform APIs get bigger,
we should provide our own dumping ground for these classes, and then
callers won't get hung up in surprising lifetime issues like this one.

BUG=106969
TEST=existing unit/heap/mem checks should cover us. Verified memcheck behavior manually.


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

[miket_OOO, 2011-12-12 21:36:42]

I am running tests now. I have not yet reproduced the bug that led me to work on
this, but I do believe I understand what caused it.

[asargent_no_longer_on_chrome, 2011-12-12 21:57:29]

LGTM 

> As platform APIs get bigger, we should provide our own 
> dumping ground for these classes, and then callers won't 
> get hung up in surprising lifetime issues like this one.

Indeed. At that point one thing we might want to design for is objects like
yours which want to live on a thread other than the IO thread (Maybe something
like PlatformAppService::IOThreadData?).

http://codereview.chromium.org/8925001/diff/3001/chrome/browser/extensions/ex...
File chrome/browser/extensions/extension_service.h (right):

http://codereview.chromium.org/8925001/diff/3001/chrome/browser/extensions/ex...
chrome/browser/extensions/extension_service.h:575: extensions::SocketController*
socket_controller();
nit: add comment that this is expected to only be called from the IO thread.

[commit-bot: I haz the power, 2011-12-13 17:39:29]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/miket@chromium.org/8925001/6001

[miket_OOO, 2011-12-13 17:40:30]

The trybots are not happy (except for linux_rel), but I've looked at every
failure on mac_rel, win_rel, linux_valgrind, and mac_valgrind, and I see no
connection between them and this change.

[commit-bot: I haz the power, 2011-12-13 17:59:10]

Try job failure for 8925001-6001 (retry) on win_rel for step "compile" (clobber
build).
It's a second try, previously, step "compile" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2011-12-13 19:04:38]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/miket@chromium.org/8925001/6001

[commit-bot: I haz the power, 2011-12-13 20:09:54]

Try job failure for 8925001-6001 (retry) on mac_rel for step "compile" (clobber
build).
It's a second try, previously, step "compile" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[commit-bot: I haz the power, 2011-12-13 20:26:40]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/miket@chromium.org/8925001/6001

[commit-bot: I haz the power, 2011-12-13 22:17:33]

Change committed as 114287