<!-- These packages are duplicated in workers and daemon-server-worker, don't require a package-info.java in each place -->
    <suppress checks="JavadocPackage"
              files=".*[/\\]platforms[/\\]core-execution[/\\]daemon-server-worker[/\\]src[/\\]main[/\\]java[/\\]org[/\\]gradle[/\\]workers[/\\][^/\\]+"/>

    <!-- These packages are duplicated in code-quality and code-quality-workers, don't require a package-info.java in each place -->

    "crossVersionTests": false
  },
  {
    "name": "scala-compiler-worker",
    "path": "platforms/jvm/scala-compiler-worker",
    "unitTests": false,
    "functionalTests": false,
    "crossVersionTests": false
  },
  {
    "name": "scaladoc-worker",
    "path": "platforms/jvm/scaladoc-worker",
    "unitTests": false,
    "functionalTests": false,
    "crossVersionTests": false

 * while a worker action that executes in a worker must declare that it executes in
 * a worker.
 *
 * However, a shared library used by both daemon and worker actions does not necessarily
 * care which runtimes it must execute in. The target runtimes it must support is a function
 * of the daemon and worker project that depends on it. Since both a daemon and worker

     *
     * The required runtimes for a project should be set if that project has
     * specific runtime requirements. For example, they must be able to run in
     * a worker (a compiler worker, test worker, worker API worker action),
     * or must be able to run in a client (TAPI model, TAPI client, CLI client).
     */
    @get:Nested
    abstract val requiredRuntimes: ModuleTargetRuntimes

            <option value="$PROJECT_DIR$/platforms/core-execution/scoped-persistent-cache" />
            <option value="$PROJECT_DIR$/platforms/core-execution/snapshots" />
            <option value="$PROJECT_DIR$/platforms/core-execution/worker-main" />
            <option value="$PROJECT_DIR$/platforms/core-execution/worker-process-services" />

* the task
* the background task
* the task function

* the template
* the template engine

* the type annotation
* the type hint

* the server worker
* the Uvicorn worker
* the Gunicorn Worker
* the worker process
* the worker class
* the workload

* the deployment
* to deploy

* the SDK
* the software development kit

* the `APIRouter`
* the `requirements.txt`

///

## Multiple Workers { #multiple-workers }

You can start multiple workers with the `--workers` command line option:

//// tab | `fastapi`

If you use the `fastapi` command:

<div class="termy">

```console
$ <font color="#4E9A06">fastapi</font> run --workers 4 <u style="text-decoration-style:solid">main.py</u>

## Decision

1. The Gradle distribution will never include a Java runtime.
   Instead, Gradle will leverage Java toolchains for the Daemon and worker processes.
2. The Gradle Daemon, Worker processes, and Tooling API client will continue to support running on different Java versions during a single Gradle invocation.
   The exact versions supported will be determined by the Gradle version.

Example:

Source (English):

```
# FastAPI in Containers - Docker { #fastapi-in-containers-docker }
```

Translate with (German) – notice the dash:

```
# FastAPI in Containern – Docker { #fastapi-in-containers-docker }
```

Do NOT translate with (German) – notice the hyphen:

```
# FastAPI in Containern - Docker { #fastapi-in-containers-docker }
```

In this example, there's a **Manager Process** that starts and controls two **Worker Processes**.

This Manager Process would probably be the one listening on the **port** in the IP. And it would transmit all the communication to the worker processes.