Introduction

ProcessPoolExecutor is intentionally higher-level than multiprocessing.Process, so it does not expose worker details through a clean public get_pids() API. If you need worker process IDs, the safest pattern is to have each worker report its own PID back to the parent rather than depending on executor internals.

Return the PID from the task itself

The easiest approach is to call os.getpid() inside the submitted function and return it with the task result.

1import os
2from concurrent.futures import ProcessPoolExecutor
3
4
5def worker(task_id):
6    return {"task": task_id, "pid": os.getpid()}
7
8
9with ProcessPoolExecutor(max_workers=3) as executor:
10    futures = [executor.submit(worker, i) for i in range(6)]
11    results = [future.result() for future in futures]
12
13print(results)

This works across Python versions because it uses only public APIs. It also tells you something useful that a plain PID list does not: which worker handled which task.

Register workers once at startup

If you want a list of unique worker PIDs instead of per-task reporting, use the pool initializer and a shared object such as a multiprocessing.Manager list.

1import os
2from concurrent.futures import ProcessPoolExecutor
3from multiprocessing import Manager
4
5worker_pids = None
6
7
8def init_worker(shared_pids):
9    global worker_pids
10    worker_pids = shared_pids
11    worker_pids.append(os.getpid())
12
13
14def square(x):
15    return x * x
16
17
18with Manager() as manager:
19    shared_pids = manager.list()
20
21    with ProcessPoolExecutor(
22        max_workers=3,
23        initializer=init_worker,
24        initargs=(shared_pids,),
25    ) as executor:
26        list(executor.map(square, [1, 2, 3, 4, 5, 6]))
27
28    print(sorted(set(shared_pids)))

That pattern is useful when you want to log worker creation, correlate system metrics, or confirm how many processes the executor actually started.

Why private executor internals are a bad dependency

You may find examples that inspect executor._processes. That can work in some versions of CPython, but it is a private implementation detail. The leading underscore matters.

Private attributes are risky because:

• they are not part of the public contract
• they can change across Python versions
• they tie your code to executor implementation details instead of intent

If your codebase only needs PIDs for debugging, the worker-reporting approach is almost always better.

Decide whether you really need ProcessPoolExecutor

Sometimes the request for child PIDs is a smell that the higher-level abstraction is the wrong fit. ProcessPoolExecutor is designed for task submission, not process lifecycle management.

If you need to:

• send signals to individual workers
• restart workers manually
• pin workers to resources
• inspect process objects directly

then multiprocessing.Process or a lower-level pool API may be a better design.

On the other hand, if the need is observability rather than control, returning os.getpid() or using an initializer is enough and keeps the code simple.

Remember that workers are reused

A process pool does not spawn a fresh child for every task. The whole point is reuse. That means the same PID will appear across many results, and that is normal.

This surprises people who expect six submitted jobs to produce six distinct child PIDs. With a pool of three workers, you should expect at most three worker PIDs, reused across tasks.

That reuse is also why task-level PID reporting is often more informative than a one-time worker list. It shows how work was distributed over time.

Common Pitfalls

The most common mistake is looking for a public ProcessPoolExecutor method that lists worker PIDs. There is no stable one.

Another mistake is depending on executor._processes in production code. It may work now and break later.

People also misread repeated PIDs as a bug. In a process pool, repeated worker IDs are expected because workers handle multiple tasks.

Finally, if your real goal is process control rather than task execution, do not fight the abstraction. Use a lower-level multiprocessing API instead.

Summary

• 'ProcessPoolExecutor does not expose worker PIDs through a stable public API.'
• The safest pattern is to have each task report os.getpid().
• Use an initializer plus a shared list when you want one-time worker registration.
• Avoid private internals such as executor._processes.
• Switch to lower-level multiprocessing primitives if direct process management is the real requirement.