Made existing user login working for linux workstation debug use case:

Made existing user login working for linux workstation debug use case:
- Resolved several threading issues in and around ParallelAuthenticator.
- Made cryptohome async calls respond on the calling thread.

BUG=chromium-os:27689
BUG=make sure that you can re-login without crashing to an an existing account on linux workstation.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=126760

[Nikita (slow), 2012-03-13 14:42:07]

lgtm

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
File chrome/browser/chromeos/login/online_attempt.cc (right):

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
chrome/browser/chromeos/login/online_attempt.cc:1: // Copyright (c) 2012 The
Chromium Authors. All rights reserved.
With changes in OnlineAttempt it seems that my CL has to be reverted:
http://codereview.chromium.org/9566006/

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
File chrome/browser/chromeos/login/online_attempt_host.cc (right):

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
chrome/browser/chromeos/login/online_attempt_host.cc:61:
content::BrowserThread::PostTask(
This could be removed and ResolveOnUIThread code moved here.
See http://codereview.chromium.org/9566006/

[Chris Masone, 2012-03-13 15:35:08]

When I originally did this, I moved all this work onto the IO thread on purpose,
to avoid blocking the UI.  I think the only reason I didn't stay on the IO
thread until I was ready to return results was because I needed to do the dbus
calls to cryptohomed on the UI thread.  I think that restriction has now been
removed.

What's changed?  Why is it now OK to do all this stuff on the UI thread?  If the
dbus-has-to-be-on-the-UI-thread issue is gone, thanks to Satoru, why wouldn't we
do everything on the IO thread?

http://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrome...
File chrome/browser/chromeos/login/auth_attempt_state.cc (right):

http://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrome...
chrome/browser/chromeos/login/auth_attempt_state.cc:73:
DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
I thought we always wanted to bend over backwards to keep things off the UI
thread

http://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrome...
File chrome/browser/chromeos/login/online_attempt.cc (right):

http://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrome...
chrome/browser/chromeos/login/online_attempt.cc:75: BrowserThread::UI,
FROM_HERE,
Isn't this going to make network traffic block the UI thread?

http://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrome...
File chrome/browser/chromeos/login/online_attempt_unittest.cc (right):

http://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrome...
chrome/browser/chromeos/login/online_attempt_unittest.cc:117: // Force IO thread
to finish tasks so I can verify |state_|.
Comment should be updated, at least

[Nikita (slow), 2012-03-13 15:40:10]

http://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrome...
File chrome/browser/chromeos/login/online_attempt.cc (right):

http://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrome...
chrome/browser/chromeos/login/online_attempt.cc:75: BrowserThread::UI,
FROM_HERE,
On 2012/03/13 15:35:09, Chris Masone wrote:
> Isn't this going to make network traffic block the UI thread?

URLFetcherImpl::Start() will actually schedule to do all of its work on IO
thread.

[Chris Masone, 2012-03-13 18:28:07]

I see now that the network stuff will not block.

So, LGTM with a few comment nits.

On 2012/03/13 15:40:10, Nikita Kostylev wrote:
>
http://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrome...
> File chrome/browser/chromeos/login/online_attempt.cc (right):
> 
>
http://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrome...
> chrome/browser/chromeos/login/online_attempt.cc:75: BrowserThread::UI,
> FROM_HERE,
> On 2012/03/13 15:35:09, Chris Masone wrote:
> > Isn't this going to make network traffic block the UI thread?
> 
> URLFetcherImpl::Start() will actually schedule to do all of its work on IO
> thread.

[zel, 2012-03-13 18:47:21]

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
File chrome/browser/chromeos/login/auth_attempt_state.cc (right):

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
chrome/browser/chromeos/login/auth_attempt_state.cc:73:
DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
On 2012/03/13 15:35:09, Chris Masone wrote:
> I thought we always wanted to bend over backwards to keep things off the UI
> thread

We are not doing anything blocking on UI thread. These are just bookkeeping
operations that which it belong on UI thread.

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
File chrome/browser/chromeos/login/online_attempt.cc (right):

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
chrome/browser/chromeos/login/online_attempt.cc:1: // Copyright (c) 2012 The
Chromium Authors. All rights reserved.
On 2012/03/13 14:42:07, Nikita Kostylev wrote:
> With changes in OnlineAttempt it seems that my CL has to be reverted:
> http://codereview.chromium.org/9566006/

Yes.

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
chrome/browser/chromeos/login/online_attempt.cc:75: BrowserThread::UI,
FROM_HERE,
On 2012/03/13 15:40:11, Nikita Kostylev wrote:
> On 2012/03/13 15:35:09, Chris Masone wrote:
> > Isn't this going to make network traffic block the UI thread?
> 
> URLFetcherImpl::Start() will actually schedule to do all of its work on IO
> thread.

URLFetcher can't be used on non-UI thread and it was used from IO thread here
originally - that's what started this change.

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
File chrome/browser/chromeos/login/online_attempt_host.cc (right):

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
chrome/browser/chromeos/login/online_attempt_host.cc:61:
content::BrowserThread::PostTask(
On 2012/03/13 14:42:07, Nikita Kostylev wrote:
> This could be removed and ResolveOnUIThread code moved here.
> See http://codereview.chromium.org/9566006/

Yes, but I don't want to change the flow of callbacks here with this CL. I want
to keep this as close as possible to the existing working code and do another
round of optimization in another CL.

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
File chrome/browser/chromeos/login/online_attempt_unittest.cc (right):

https://chromiumcodereview.appspot.com/9694022/diff/4005/chrome/browser/chrom...
chrome/browser/chromeos/login/online_attempt_unittest.cc:117: // Force IO thread
to finish tasks so I can verify |state_|.
On 2012/03/13 15:35:09, Chris Masone wrote:
> Comment should be updated, at least

Done.