Creating objects USING_FAST_MALLOC in the MTS fail due to WTF being allocated and initialized after the main thread. This CL ensures that that happens before the MT is created fixing issues like crbug.com/584196.
Bug: 1058645
Change-Id: I6c53e7b5cd48532c2e5ff0d3313e911a5ef4fc6d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2103787
Commit-Queue: Katie Dillon <kdillon@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Scott Haseley <shaseley@chromium.org>
Cr-Commit-Position: refs/heads/master@{#761573}
These asserts are no longer actively being used for debugging.
When this is compiled on the Android component build, the linker
cannot find the extern bool declared by another shared library.
This patch disables the InProcessRenderThread checks, which were
intended for debugging in production, so that developers can at
least attempt to use the component build on Android.
Bug: Internal b/64440217
Bug: 514141
Test: chromecast internal Android component build
Change-Id: Iac24c87867e218f98c130677e6baff9142a7fe84
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1898812
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Simeon Anfinrud <sanfin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#714138}
Renderer client id is propagated via command line flags, so in single
process mode RenderThreadImpl gets initialized with the default client
id of 1, whereas the browser allocates a globally unique client id for
each renderer.
Viz frame sinks are embedded in a hierarchy which identifies embedders
by their client ids. So requests made by the renderer to embed other
surfaces are rejected by EmbeddedFrameSinkProviderImpl because the
client ids don't match.
This CL fixes that by propagating the client id from the browser to
RenderThreadImpl in single process mode, and includes related minor code
cleanup.
Bug: 1015988
Change-Id: I758f19df05ad6dc083e01e8cfc760f76ca1831a2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1869376
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Sunny Sachanandani <sunnyps@chromium.org>
Cr-Commit-Position: refs/heads/master@{#708319}
Previously, the constructor of ChildProcess called
ChildProcess::InitializeTaskScheduler() to initialize TaskScheduler.
RenderProcessImpl overrode this method to initialize TaskScheduler
with custom arguments. Unfortunately, the constructor of a base
class cannot call methods from a derived class.
This CL removes the virtual ChildProcess::InitializeTaskScheduler()
method. RnederProcessImpl passes its custom TaskScheduler
initialization arguments to the constructor of ChildProcess.
BUG=664996
Review-Url: https://codereview.chromium.org/2687903003
Cr-Commit-Position: refs/heads/master@{#449785}
WebView somehow ends up shutting down and reinitialising blink in the
same process sometimes, which isn't supported. We have no idea how to
reproduce this, so this change adds assertions that verify that we never
shut down InProcessRendererThread unless the browser is already being
shut down. WebView only exits by the process being SIGKILLed, so the
shutdown path is intended to be unreachable.
This is a temporary change that will be reverted once we've found the
stack that leads to the shutdown being initiated.
BUG=514141
Review-Url: https://codereview.chromium.org/1900513003
Cr-Commit-Position: refs/heads/master@{#391207}
This would be very helpful for analyzing traces.txt of ANR logs.
BUG=570819
Review URL: https://codereview.chromium.org/1518213002
Cr-Commit-Position: refs/heads/master@{#365953}
Renderer main thread will run ChannelProxy::SetListenerTaskRunner()
to set listener task runner, but the task runner may be accessed on
IPC thread at the same time.
This CL is to fix the race condition.
TBR=nasko@chromium.org
BUG=479684
Review URL: https://codereview.chromium.org/1227303002
Cr-Commit-Position: refs/heads/master@{#338425}
The globally-set TaskRunner doesn't work because some child
thread can run inside the browser process even when other
child threads run in their own processes.
For example, there is a configuration where GpuChildThread
being in-process while RenderThreadImpl isn't.
It is troublesome once non-renderer child processes adopt
ChannelMojo.
This CL eliminates the global in-process IO task runner
and instead, passes an IO runnner for each thread
if it is configured as an in-process mode.
Note that InProcessChildThreadParams object is introuced to
clarify that the parameter is for in-process mode.
This is a spin-off from https://codereview.chromium.org/960693003/.
R=jamesr@chromium.org, rockot@chromium.org, jam@chromium.org
BUG=377980
Review URL: https://codereview.chromium.org/987693005
Cr-Commit-Position: refs/heads/master@{#321047}
