New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 832310 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Populate the threading assumption in PortAllocator to downstream dependencies

Project Member Reported by qingsi@chromium.org, Apr 12 2018

Issue description

WebRTC is redesigning the thread model in PortAllocator and its subclasses. The new threading assumption is that every method of PortAllocator (including the destructor) must be called on the same thread after Initialize is called. This allows a PortAllocator subclass to be constructed and configured on one thread, and passed into an object that uses it on a different thread.

The above new assumption should be reflected in downstream dependencies that directly use PortAllocator and its subclasses. In the long term, we should create a PortAllocatorInterface that shields the downstream project from directly using the WebRTC internal implementation.
 

Comment 1 by qingsi@chromium.org, Apr 12 2018

Labels: -Pri-3 Pri-2
Project Member

Comment 2 by bugdroid1@chromium.org, Apr 13 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cf4ecdadcc0bd692eb78c03eca50e45ee57701cf

commit cf4ecdadcc0bd692eb78c03eca50e45ee57701cf
Author: Qingsi Wang <qingsi@google.com>
Date: Fri Apr 13 23:04:58 2018

Initialize before using PortAllocator and its subclasses.

WebRTC is redesigning the thread model in PortAllocator and its
subclasses. The new threading assumption is that every method of
PortAllocator (including the destructor) must be called on the same
thread after Initialize is called. This allows a PortAllocator subclass
to be constructed and configured on one thread, and passed into an
object that uses it on a different thread.

The above new assumption should be reflected in Chromium objects that
directly use the WebRTC implementation of PortAllocator.

Bug:  832310 
Change-Id: I3610a714320f6e230e4e3e15c1101bcafbcc175c
Reviewed-on: https://chromium-review.googlesource.com/1011257
Reviewed-by: Yuwei Huang <yuweih@chromium.org>
Commit-Queue: Qingsi Wang <qingsi@google.com>
Cr-Commit-Position: refs/heads/master@{#550774}
[modify] https://crrev.com/cf4ecdadcc0bd692eb78c03eca50e45ee57701cf/remoting/protocol/port_allocator.cc
[modify] https://crrev.com/cf4ecdadcc0bd692eb78c03eca50e45ee57701cf/remoting/test/fake_port_allocator.cc

Project Member

Comment 3 by bugdroid1@chromium.org, Apr 17 2018

Labels: merge-merged-testbranch
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cf4ecdadcc0bd692eb78c03eca50e45ee57701cf

commit cf4ecdadcc0bd692eb78c03eca50e45ee57701cf
Author: Qingsi Wang <qingsi@google.com>
Date: Fri Apr 13 23:04:58 2018

Initialize before using PortAllocator and its subclasses.

WebRTC is redesigning the thread model in PortAllocator and its
subclasses. The new threading assumption is that every method of
PortAllocator (including the destructor) must be called on the same
thread after Initialize is called. This allows a PortAllocator subclass
to be constructed and configured on one thread, and passed into an
object that uses it on a different thread.

The above new assumption should be reflected in Chromium objects that
directly use the WebRTC implementation of PortAllocator.

Bug:  832310 
Change-Id: I3610a714320f6e230e4e3e15c1101bcafbcc175c
Reviewed-on: https://chromium-review.googlesource.com/1011257
Reviewed-by: Yuwei Huang <yuweih@chromium.org>
Commit-Queue: Qingsi Wang <qingsi@google.com>
Cr-Commit-Position: refs/heads/master@{#550774}
[modify] https://crrev.com/cf4ecdadcc0bd692eb78c03eca50e45ee57701cf/remoting/protocol/port_allocator.cc
[modify] https://crrev.com/cf4ecdadcc0bd692eb78c03eca50e45ee57701cf/remoting/test/fake_port_allocator.cc

Status: Fixed (was: Untriaged)

Sign in to add a comment