[task] Expose TaskRunner::GetCurrentThreadType() [chromium/src : main]
0 views
Skip to first unread message
Etienne Pierre-Doray (Gerrit)
Feb 5, 2026, 4:45:27 PMFeb 5
to Francois Pierre Doray, Jerome Jiang, Mirko Bonadei, Enterprise Policy Reviews, Peter Beverloo, Chromium LUCI CQ, AyeAye, chromium...@chromium.org, mar...@chromium.org, jz...@chromium.org, mfoltz+wa...@chromium.org, fgal...@chromium.org, permissio...@chromium.org, zackha...@chromium.org, druber...@chromium.org, mercer...@google.com, xinghui...@chromium.org, lens-chrome...@google.com, vakh+safe_br...@chromium.org, nwoked...@chromium.org, stanfie...@google.com, andysjl...@chromium.org, chrome-intell...@chromium.org, penghuan...@chromium.org, feature-me...@chromium.org, devtools...@chromium.org, net-r...@chromium.org, cblume...@chromium.org, chrome-intelligence-te...@google.com, kinuko...@chromium.org, blink-...@chromium.org, scheduler-...@chromium.org, chikamu...@chromium.org, scheduler-b...@chromium.org, network-ser...@chromium.org, scheduler...@chromium.org
Attention needed from Francois Pierre Doray
Etienne Pierre-Doray added 1 comment![]( "Open in Gerrit")
Patchset-level comments
Related details
Attention is currently required from:
- Francois Pierre Doray
Submit Requirements:
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Francois Pierre Doray (Gerrit)
Feb 6, 2026, 10:31:13 AMFeb 6
to Etienne Pierre-Doray, Jerome Jiang, Mirko Bonadei, Enterprise Policy Reviews, Peter Beverloo, Chromium LUCI CQ, AyeAye, chromium...@chromium.org, mar...@chromium.org, jz...@chromium.org, mfoltz+wa...@chromium.org, fgal...@chromium.org, permissio...@chromium.org, zackha...@chromium.org, druber...@chromium.org, mercer...@google.com, xinghui...@chromium.org, lens-chrome...@google.com, vakh+safe_br...@chromium.org, nwoked...@chromium.org, stanfie...@google.com, andysjl...@chromium.org, chrome-intell...@chromium.org, penghuan...@chromium.org, feature-me...@chromium.org, devtools...@chromium.org, net-r...@chromium.org, cblume...@chromium.org, chrome-intelligence-te...@google.com, kinuko...@chromium.org, blink-...@chromium.org, scheduler-...@chromium.org, chikamu...@chromium.org, scheduler-b...@chromium.org, network-ser...@chromium.org, scheduler...@chromium.org
Attention needed from Etienne Pierre-Doray
Francois Pierre Doray added 1 comment![]( "Open in Gerrit")
File base/task/task_runner.h
Line 62, Patchset 18 (Latest):
public:Francois Pierre Doray . unresolved
The comment refers to "this TaskRunner", but this is a static method, so it's not so clear what "this TaskRunner" means. It's definitely not the TaskRunner on which this is called in:
`task_runner->GetCurrentThreadType()`
To reduce confusion, I suggest making this a standalone function. Depending on where you plan to use this, it could be in the anonymous namespace?
Related details
Attention is currently required from:
- Etienne Pierre-Doray
Submit Requirements:
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Scott Haseley (Gerrit)
Feb 6, 2026, 12:49:50 PMFeb 6
to Etienne Pierre-Doray, Francois Pierre Doray, Jerome Jiang, Mirko Bonadei, Enterprise Policy Reviews, Peter Beverloo, Chromium LUCI CQ, AyeAye, chromium...@chromium.org, mar...@chromium.org, jz...@chromium.org, mfoltz+wa...@chromium.org, fgal...@chromium.org, permissio...@chromium.org, zackha...@chromium.org, druber...@chromium.org, mercer...@google.com, xinghui...@chromium.org, lens-chrome...@google.com, vakh+safe_br...@chromium.org, nwoked...@chromium.org, stanfie...@google.com, andysjl...@chromium.org, chrome-intell...@chromium.org, penghuan...@chromium.org, feature-me...@chromium.org, devtools...@chromium.org, net-r...@chromium.org, cblume...@chromium.org, chrome-intelligence-te...@google.com, kinuko...@chromium.org, blink-...@chromium.org, scheduler-...@chromium.org, chikamu...@chromium.org, scheduler-b...@chromium.org, network-ser...@chromium.org, scheduler...@chromium.org
Attention needed from Etienne Pierre-Doray
Scott Haseley added 1 comment![]( "Open in Gerrit")
File third_party/blink/renderer/platform/scheduler/common/task_priority.cc
Line 54, Patchset 18 (Latest):
base::ThreadType ToThreadType(TaskPriority priority) {Scott Haseley . unresolved
Hi, sorry for the drive-by, but I have a question about this: how will this be used in the renderer, and is this the best fit for thread type (vs. UseCase)?
We use priority in blink a lot for relative ordering of various things, and I don't know how well that really matches thread priority. For example, during loading we:
- Run image loading tasks at extremely high priority so it happens before the next paint (i.e. this is coordinated with rendering priority), which helps prevent layout shift (by a good amount IIRC) and has a small LCP benefit (~1 frame max improvement).
- We periodically bump up rendering priority (to very high) to balance loading tasks and rendering.
- We also use very high priority internally for script continuation, e.g. to break up executing module scripts during loading, where we want input and maybe rendering to run, but not other things.
In all cases I don't know that the elevated priority implies a difference in thread priority compared to the other loading tasks (normal priority)? Some other recent features, e.g. [1], are using UseCase to determine drive performance settings, so I'm wondering if we should align this (assuming this will drive thread priority).
Reply all
Reply to author
Forward
0 new messages