Allow cross-thread destruction of RTCSessionDescriptionRequest objects.

Allow cross-thread destruction of RTCSessionDescriptionRequest objects.

ligjingle may queue incoming CreateOffer/Answer session requests from
the browser process. Should the RTC session be shut down before those
requests have been processed & queue is drained, the libjingle thread
will destruct these requests as part the session shutdown. (See
associated bug for stack trace of when&how this happens.)

Embedded in those requests are references to Oilpan heap objects, by way
of Persistent<RTCSessionDescriptionRequest>. As Persistent<>s are thread
local, requiring that the thread that created & registered them is the
one that finalizes, the destruction performed by the libjingle thread
runs into trouble.

Hence, allow libjingle to destruct CreateSessionDescriptionRequests by
having WebRTCSessionDescriptionRequests refer to the Oilpan Blink object
by way of a CrossThreadPersistent<>. It imposes no same-thread restriction
wrt destruction.

R=haraken, tommi, philipj
BUG=537745
Committed: https://crrev.com/b16338dd1caf186c3601ce4dcd209670e9f2f36f
Cr-Commit-Position: refs/heads/master@{#351783}

[sof, 2015-10-01 07:48:56]

sigbjornf@opera.com changed reviewers:
+ oilpan-reviews@chromium.org, tommi@chromium.org, tommyw@chromium.org

[sof, 2015-10-01 07:48:57]

please take a look.

I had a look around in the libjingle & webrtc code implicated here to see if
there were other objects requiring the same treatment to their WebPrivatePtr<>
references, but couldn't spot any. But I don't know the code nor lifetime
assumptions made... :) Any object that might end up being deref'ed&destructed on
a non-main thread will require same/similar treatment, if it embeds a
WebPrivatePtr<> referring to a heap object.

[haraken, 2015-10-01 08:03:26]

non-owner LGTM

[tommi (sloooow) - chröme, 2015-10-01 10:35:21]

tommi@chromium.org changed reviewers:
- tommyw@chromium.org

[tommi (sloooow) - chröme, 2015-10-01 10:35:22]

-Tommy as he's away atm
+ Guido FYI

lgtm.  thanks for the detailed background.

[sof, 2015-10-01 10:42:19]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2015-10-01 10:42:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1380023004/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1380023004/1

[commit-bot: I haz the power, 2015-10-01 10:50:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-01 10:50:59]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[sof, 2015-10-01 11:00:39]

sigbjornf@opera.com changed reviewers:
+ jochen@chromium.org, philipj@opera.com

[sof, 2015-10-01 11:00:40]

public/ needs owner approval.

jochen@, philipj@ ptal? thanks.

[philipj_slow, 2015-10-01 12:24:20]

lgtm

[sof, 2015-10-01 12:29:51]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2015-10-01 12:30:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1380023004/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1380023004/1

[commit-bot: I haz the power, 2015-10-01 12:34:57]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-10-01 12:35:29]

Patchset 1 (id:??) landed as
https://crrev.com/b16338dd1caf186c3601ce4dcd209670e9f2f36f
Cr-Commit-Position: refs/heads/master@{#351783}