Renderer main thread task runner from //content/app

2 views
Skip to first unread message

Sam Maier

unread,
Jul 18, 2025, 5:08:29 PMJul 18
to scheduler-dev

Hi scheduler-dev team,

I'm working on native-only renderers on Android (no Java run in the process at all), with an early prototype from the Android OS team. My code is the entrypoint and is responsible for launching ContentMain and kicking off the renderer. I've run into a threading issue where I need to post a task from an external thread (managed by the Android OS) to the renderer's main thread, and I'm looking for the correct and most robust way to do this.

The Scenario:

I am implementing the ChildProcessService AIDL interface. One of its methods, onMemoryPressure, is called directly by the Android OS on a binder thread to notify the process of memory pressure. Inside this method, I need to call base::MemoryPressureListener::NotifyMemoryPressure, which was mentioned should be run on the renderer main thread.

The Issue:

The problem is obtaining a base::SingleThreadTaskRunner for the renderer's main thread from this external binder thread. Unlike the browser process which has a well-known BrowserThread::UI task trait, there doesn't appear to be a canonical, globally-accessible way to get the renderer's main thread task runner.

What I've Investigated So Far:

  1. base::SingleThreadTaskRunner::GetCurrentDefault(): This only works when called from the main thread post-startup. My attempts to cache the TaskRunner during early startup on the main thread failed because it's not available until well into ContentMain's execution, by which point my initialization code has already long finished.

  2. Blink/Deprecated APIs: I've seen blink::Thread::MainThread() and, blink main thread task traits. From what I can tell, //content/app should not be using blink. RenderThreadImpl::DeprecatedGetMainTaskRunner() also exists and is definitely bad and not intended to be used.

  3. Add a new API to get the renderer main thread: I'm not sure where this would be appropriate, but sometime during startup (after all the base::threading stuff is initialized), I could store a global main thread task runner and expose it to content/app/android/javaless_child_process_service.cc

Is there some fourth option I've missed? What should I be doing here?

Dave Tapuska

unread,
Jul 18, 2025, 5:13:28 PMJul 18
to Sam Maier, scheduler-dev

--
You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAHEKBaqbTGVG2QxiuKMadXuaVTsUtKoJ59Hrc1WV8b%2BNHQ%2BQdQ%40mail.gmail.com.

Gabriel Charette

unread,
Jul 24, 2025, 3:52:21 PMJul 24
to Dave Tapuska, Patrick Monette, Sam Maier, scheduler-dev
Hey Sam,

This came up again this week with +Patrick Monette needing access to the "main thread" for an API in //base. We decided, since this was the second use case in a week, to add SingleThreadTaskRunner::GetMainThreadDefaultTaskRunner() (alongside SequencedTaskRunner::GetCurrentDefaultTaskRunner()). (CL incoming)

Cheers,
Gab

Reply all
Reply to author
Forward
0 new messages