This document explains how components relate to jobs, processes, and threads.
There is no inherent relationship between component instances and a Zircon task (job, process, or thread). It's best to avoid a mental model with a fixed relationship between components and Zircon tasks.
No direct relationship
There's no inherent relationship between Zircon tasks and components.
To illustrate that there is no inherent relationship, consider that a component may:
- Have zero or more jobs.
- Have zero or more processes.
- Have zero or more threads.
- Share a job with other components.
- Share a process with other components.
- Share a thread with other components.
Different components are expressed, or implemented, differently (even in ways we haven't yet explored).
The way components and Zircon tasks relate is dynamic. On initial inspection it may appear that there is a hierarchy, but there is no hierarchy between components and processes.
Here are some examples of specific component types to illustrate the nature of the component abstraction:
- Dart Runner
- The Dart runner, which itself is a component, is a single process that runs separate Dart components in separate threads.
- ELF binaries
- The ELF runner, which itself is a component, starts a process to kick off the component and then lets that process spawn additional processes as part of the same component.
- Web page components (using Web Runner)
- The Web Runner uses multiple processes in a single component.