Currently base::SetIOThreadTaskLoop() and base::GetIOThreadTaskLoop() deal only with the base class base::TaskLoop. However, consumers of base::GetIOThreadTaskLoop() (like mage) are eventually going to rely on it returning a base::TaskLoopForIO, so it can use the specific base::TaskLoopForIO methods that are not provided by just a plain old base::TaskLoop.

Until we fix this, all users of base::GetIOThreadTaskLoop() are going to have to statically cast the return TaskLoop into a TaskLoopForIO in order to use IO-specific methods, like registering a socket reader etc.

We could fix this right now, but it would involve putting even platform-specific #ifdefs in the code Linux doesn't support TaskLoopForIO yet. Instead we should consider this blocked on domfarolino/browser#33 so that we can remove all platform-specific #ifdefs around TaskLoopForIO usages, and fix this trivial bug.

Anyone can take this if they'd like. Basically base::Thread::delegate_ is accessed on multiple threads but is not protected by a mutex or anything, which is a little sketchy. I'm pretty sure there are no problems with the current code, but we should:

1. Synchronize access to the variable anyways to be safe
2. Do a kinda deep-dive to see if there is any way to exploit the current code to cause a bug, and if so, consider writing a test that would expose the bug, but that would pass after (1). I say "consider" writing a test because in order to actually write the test to deterministically exploit a subtle race condition it might require some weird test-specific hooks which might not be worth implementing. But we should find out for sure.

base::Thread does not create its Thread::Delegate until Start() is called on the thread. Because of this, base::Thread::GetTaskRunner() will crash, which in itself is fine (you just need to be sure to know that you can't do this in practice). But the real issue is that you can't actually queue tasks until you call thread.Start(), which is annoying.

I think it would be a better design if we allowed for the queueing of tasks on a thread that has not yet started. This would also allow us to better-exercise the task queueing/execution infra in tests, since we could verify that multiple queued tasks (even of different types) are executed back-to-back, and not accidentally held-up behind each other.

To accomplish this, I think Thread should eagerly create its Thread::Delegate, which would allow us to get task runners synchronously after a Thread is created. It might be as easy as that... but then again it might not be.

If someone is interested in taking this, go for it! Otherwise, I will at some point. cc @pmusgrave