Fix QUIC alternate protocol behavior so that that main job does not wait

Fix QUIC alternate protocol behavior so that that main job does not wait
for the QUIC job to finish.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=208099

[Ryan Hamilton, 2013-06-21 23:33:03]

This is the fix we talked about for QUIC Alternate-Protocol handling.  I'll work
on adding some better comments now.

[willchan no longer on Chromium, 2013-06-21 23:55:45]

LGTM mod my one question. Is that an issue?

https://codereview.chromium.org/17247006/diff/1/net/quic/quic_client_session.cc
File net/quic/quic_client_session.cc (left):

https://codereview.chromium.org/17247006/diff/1/net/quic/quic_client_session....
net/quic/quic_client_session.cc:73: DCHECK(callback_.is_null());
Why did this change?

[Ryan Hamilton, 2013-06-22 00:00:36]

Thanks for the quick review!

https://codereview.chromium.org/17247006/diff/1/net/quic/quic_client_session.cc
File net/quic/quic_client_session.cc (left):

https://codereview.chromium.org/17247006/diff/1/net/quic/quic_client_session....
net/quic/quic_client_session.cc:73: DCHECK(callback_.is_null());
On 2013/06/21 23:55:45, willchan wrote:
> Why did this change?

Ah, right.  This was a check that raman added when we ported the code to
Chromium.  At the time, we though that this check was a good sanity check
because it should never happen that we are destroyed while we are connecting. 
However, this turns out not to be correct.  If we shutdown during a connection,
we hit this.  In the new test I added, that's exactly what happens.  The
QuicClientSession is still connecting (and hence the callback is set) when the
stack shuts down.

[willchan no longer on Chromium, 2013-06-22 00:14:33]

https://codereview.chromium.org/17247006/diff/1/net/quic/quic_client_session.cc
File net/quic/quic_client_session.cc (left):

https://codereview.chromium.org/17247006/diff/1/net/quic/quic_client_session....
net/quic/quic_client_session.cc:73: DCHECK(callback_.is_null());
On 2013/06/22 00:00:36, Ryan Hamilton wrote:
> On 2013/06/21 23:55:45, willchan wrote:
> > Why did this change?
> 
> Ah, right.  This was a check that raman added when we ported the code to
> Chromium.  At the time, we though that this check was a good sanity check
> because it should never happen that we are destroyed while we are connecting. 
> However, this turns out not to be correct.  If we shutdown during a
connection,
> we hit this.  In the new test I added, that's exactly what happens.  The
> QuicClientSession is still connecting (and hence the callback is set) when the
> stack shuts down.

Great, sounds good.

[commit-bot: I haz the power, 2013-06-22 19:32:36]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rch@chromium.org/17247006/1

[commit-bot: I haz the power, 2013-06-22 20:00:36]

Retried try job too often on ios_dbg_simulator for step(s) net_unittests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=ios_dbg_si...

[commit-bot: I haz the power, 2013-06-22 20:36:57]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rch@chromium.org/17247006/21001

[commit-bot: I haz the power, 2013-06-22 22:43:33]

Change committed as 208099