Make sure we process all pending offer/answer requests before terminating.

Make sure we process all pending offer/answer requests before terminating.
This fixes a bug in the WebRtcSessionDescriptionFactory where messages would be dropped or worse yet processed after the factory was deleted.

BUG=chromium:507307
Committed: https://crrev.com/0f620f4e318a162e7a251133e7a8ddea5188b9bb
Cr-Commit-Position: refs/heads/master@{#9557}

[tommi, 2015-07-09 08:50:41]

tommi@webrtc.org changed reviewers:
+ pbos@webrtc.org

[pbos-webrtc, 2015-07-09 09:09:22]

lgtm

https://codereview.webrtc.org/1231823002/diff/1/talk/app/webrtc/peerconnectio...
File talk/app/webrtc/peerconnection.cc (right):

https://codereview.webrtc.org/1231823002/diff/1/talk/app/webrtc/peerconnectio...
talk/app/webrtc/peerconnection.cc:341: ASSERT(signaling_thread()->IsCurrent());
CHECK/DCHECK?

https://codereview.webrtc.org/1231823002/diff/1/talk/app/webrtc/webrtcsession.cc
File talk/app/webrtc/webrtcsession.cc (right):

https://codereview.webrtc.org/1231823002/diff/1/talk/app/webrtc/webrtcsession...
talk/app/webrtc/webrtcsession.cc:501: ASSERT(signaling_thread()->IsCurrent());
same

https://codereview.webrtc.org/1231823002/diff/1/talk/app/webrtc/webrtcsession...
File talk/app/webrtc/webrtcsession_unittest.cc (right):

https://codereview.webrtc.org/1231823002/diff/1/talk/app/webrtc/webrtcsession...
talk/app/webrtc/webrtcsession_unittest.cc:3874:
rtc::Thread::Current()->ProcessMessages(10);
Is this long enough to not be flaky? Is it just to trigger killing off the
factory?

[tommi, 2015-07-09 09:17:58]

Quit() instead of ProcessMessage

[tommi, 2015-07-09 09:18:16]

https://codereview.webrtc.org/1231823002/diff/1/talk/app/webrtc/peerconnectio...
File talk/app/webrtc/peerconnection.cc (right):

https://codereview.webrtc.org/1231823002/diff/1/talk/app/webrtc/peerconnectio...
talk/app/webrtc/peerconnection.cc:341: ASSERT(signaling_thread()->IsCurrent());
On 2015/07/09 09:09:22, pbos-webrtc wrote:
> CHECK/DCHECK?

We might need to merge this change to other branches, so I'd like to make that
change separately and use what's already being used in this file for now.

https://codereview.webrtc.org/1231823002/diff/1/talk/app/webrtc/webrtcsession...
File talk/app/webrtc/webrtcsession_unittest.cc (right):

https://codereview.webrtc.org/1231823002/diff/1/talk/app/webrtc/webrtcsession...
talk/app/webrtc/webrtcsession_unittest.cc:3874:
rtc::Thread::Current()->ProcessMessages(10);
On 2015/07/09 09:09:22, pbos-webrtc wrote:
> Is this long enough to not be flaky? Is it just to trigger killing off the
> factory?

All messages will have been posted to the message queue at this point, so
processing should be fast (on physical machines <1ms).  However some bots are
incredibly slow... hmm... yeah, I think there's a better way to do this.  I'll
just Quit() the message loop.  That will process all pending messages (which is
what I want) and then return.  That'll also mean the test will run faster in
most cases.

[pbos-webrtc, 2015-07-09 09:21:15]

Great, lgtm.

[tommi, 2015-07-09 09:24:04]

The CQ bit was checked by tommi@webrtc.org

[commit-bot: I haz the power, 2015-07-09 09:24:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1231823002/20001

[commit-bot: I haz the power, 2015-07-09 10:25:08]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-07-09 10:25:16]

Patchset 2 (id:??) landed as
https://crrev.com/0f620f4e318a162e7a251133e7a8ddea5188b9bb
Cr-Commit-Position: refs/heads/master@{#9557}