There is only one remaining use of NotificationService which is
pending removal [1]. In the meantime, we can start removing
supporting code for NotificationService which is not needed for this
remaining case.
In particular:
- Remove checks for a non-null NotificationService in code that
otherwise doesn't use it.
- NotificationService is no longer used on the IO thread, so we no
longer create one there.
- Move code that no longer needs to be in content public into the
content Impl classes.
- Remove code that's dead and trivial to remove or code that can be
defaulted by the compiler.
Note that some NotificationService functionality is now essentially
dead code outside of unit tests, but this CL leaves the core
implementation alone, given that's it's just going to be deleted
entirely.
[1] b/301214499
Bug: 40327896
Change-Id: Id70b6ead574d401f63b4d20b845b1c6e96b3b575
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5622038
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1314368}
As a part of the CodeHealthRotation, this CL removes the expired
histograms.
OBSOLETE_HISTOGRAM[NetworkService.ShutdownTime]=The histogram was expired as of M85.
Bug: 1499454
Change-Id: I0af35f7aa43ce52a6eb609329e86ff282839ed5f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5039245
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Commit-Queue: Minoru Chikamune <chikamune@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1227150}
It's left over from when the network service was run in the browser
process, but that's no longer the case. All consumers have now been
migrated, so we can at at last delete it.
Bug: 1010491
Change-Id: I5191cb715e70c64eb865d3309ac31fcb02b8a081
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3702852
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1015073}
If the browser goes to background and back this will be reset. This cl doesn't yet handle setting the affinity to default value when the browser or renderer is in the background.
Bug: 1257237
Change-Id: I5cbdf4f6518d8d73acfe0aa3fcc1125b7428201b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3230003
Auto-Submit: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Clark DuVall <cduvall@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#932761}
Finch will be used to determine which threads run on big or bigger
cores. There's no logic yet to do this for just foreground renderers or
apps; the intent is to first gather data on what is the biggest
performance benefit this could yield along with the corresponding
worst-case power drain. The other purpose is to see how the numbers from
the field compare to what we see on Pinpoint.
Bug: 1257237
Change-Id: I5ddf996c8a4797c7787549a405c4c91e65e705c0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3216304
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Cr-Commit-Position: refs/heads/main@{#931674}
This modifies Browser/ChildProcessHost and ChildThreadImpl to support
child processes which never establish a legacy IPC Channel, and
modifies UtilityProcessHost and UtilityThreadImpl to take advantage of
this.
This makes utility processes the first type of process to be completely
free of legacy IPC. GPU processes can follow shortly hereafter.
To facilitate this change, a few other details are modified here:
- BrowserChildProcessObserver no longer exposes a separate
BrowserProcessHostConnected event. The only two consumers are
migrated to BrowserChildProcessLaunchedAndConnected. This avoids
potential re-entrancy issues when launching a process, since any
hosts not using legacy IPC are considered to be connected
synchronously as soon as launch is started.
- Browser/ChildProcessHost no longer acknowledges the PID received
from the child process in IPC::Listener::OnChannelConnected,
instead using the PID exposed directly from the
ChildProcessLauncher. This is consistent whether or not the
host creates a legacy IPC channel.
Bug: 616980, 993189
Change-Id: I881db61db335b70b658fe0dbf0c149703e7219e4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2959467
Commit-Queue: Ken Rockot <rockot@google.com>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Alex Gough <ajgo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#893209}
