Wrapping my head around base::Thread/blink::Thread/RenderThread/MainThread/SimpleThread

[Francisco Tolmasky]

I am trying to wrap my head around the variety of different Thread classes in Blink and how they relate to each-other (base::Thread, base::SimpleThread, blink::Thread, blink::MainThread,  blink::NonMainThread, blink::RenderThread, and Impl varieties of those sometimes). If there is a good summary of this somewhere -- I'd love to a link, I did some searching but couldn't find anything around this specific topic (the "Threading and Tasks in Chrome" documentation refers to Threads mainly in the abstract, not diving into the specific classes, or when you should use beach one). As far as I've gathered, I think the distinctions seem to arrise from:

1. "Descriptive" vs. "Prescriptive" threads. Namely, I would describe the "MainThread" classes as being "descriptive", in that they aren't used to actually *start* any new threads, but rather to create a representation of an existing thread that you are on. On the other hand, most (all?) other thread classes appear to be "prescriptive," or put another way, you can actually start a thread with them.

2. The (apparent) significant overlap arrises from each subsequent layer in the stack wanting their own more "specialized" representation of a thread. At the very bottom, base::Thread has no knowledge of web stuff at all, and as you climb up, each layer has a more sophisticated description of a Thread's purpose.

Is this more or less it? There is no "canonical" main thread object, whoever happens to care about that sort of thing in isolated enough components of base/blink/chrome just takes it upon themselves to manually identify the main thread and store a (unique) pointer to their custom representation of it?

The reason I ask is that I am wanting to run Blink in a background thread, I believe the same way content_shell does in single-process mode, but I was fairly confused about InProcessRenderThread existing simultaneously to RenderThreadImpl existing simultaneously to MainThread, etc, and I am just scared that there might be some delicate subtlety to this that I should look out for.

Thanks!

Francisco

[Stefan Zager]

There are definitely people who can answer this better than I can, but here are some breadcrumbs...

Instances of BrowserThread run in the browser process, and to the extent that there's a thread that rules all other threads, it's BrowserThread::UI. In multi-process mode (the default, even for content_shell) the render main thread is the "in charge" thread for a renderer process. In single-process mode the renderer main thread runs in the same process as the browser threads, but I don't think it's quite accurate to describe it as running "in the background".

As for running blink in a background thread, your best bet is to embed at the content layer boundary and use the --single-process flag, as you would for content_shell. You shouldn't have to worry about management of other thread types, but there *will* be a bunch of threads spawned; that's an inseverable aspect of the architecture.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/54707858-20f7-48c7-a9d4-987710ad276dn%40chromium.org.