[bugfix] Shut down Inductor workers gracefully

[Satyam-53]

Purpose

Fix noisy and potentially incomplete worker shutdown after torch.compile inference.

Compiled multiprocessing runs could end with:

Exception ignored in atexit callback: shutdown_compile_workers
...
SystemExit

FastVideo allowed workers only five seconds to exit before sending SIGTERM. On slower or low-priority hosts, the signal could interrupt PyTorch Inductor while its atexit callback was waiting for compiler subprocesses to stop.
Worker cleanup was also invoked twice: once by the shutdown RPC and again from the worker process's finally block.

Changes

Close an already-initialized PyTorch Inductor compilation pool during normal worker shutdown.

• Inspect sys.modules instead of importing Inductor, so eager inference does not initialize compiler state during shutdown.

Make WorkerMultiprocProc.shutdown() idempotent.
Extend the parent worker's graceful shutdown period from 5 seconds to 30 seconds.
Join workers against a shared deadline instead of polling.
Preserve the existing SIGTERM and SIGKILL fallbacks for unresponsive workers.
Add CPU regression coverage for:- idempotent worker and compiler-pool cleanup;

• cleanup of an already-loaded Inductor pool;
• avoiding an Inductor import for eager workers;
• workers requiring more than the previous five-second grace period;
• workers that ignore graceful shutdown and SIGTERM.

Test Plan

conda run -n fastvideo python -m pytest
fastvideo/tests/worker/test_multiproc_executor.py -q

conda run -n fastvideo python -m pytest
fastvideo/tests/worker/ -q

conda run -n fastvideo pre-commit run --files
fastvideo/worker/multiproc_executor.py
fastvideo/tests/worker/test_multiproc_executor.py

git diff --check

[mergify]

Merge Protections

🔴 1 of 1 protections blocking · waiting on 👀 reviews and 🤖 CI

	Protection	Waiting on
🔴	PR merge requirements	👀 reviews and 🤖 CI

🔴 PR merge requirements

Waiting for

• #approved-reviews-by>=1
• check-success=full-suite-passed

This rule is failing.

• #approved-reviews-by>=1
• check-success=full-suite-passed
• check-success=fastcheck-passed
• check-success~=pre-commit
• title~=(?i)^\[(feat|feature|bugfix|fix|refactor|perf|ci|doc|docs|misc|chore|kernel|new.?model|skill|skills|infra)\]

[SolitaryThinker]

One blocking shutdown-state issue. The normal path and test coverage look good, and I verified the targeted tests plus pre-commit locally, but an interrupted or failed cleanup can still execute worker teardown twice—the failure mode this PR is intended to remove. See the inline comment for a reproducer and suggested state-machine fix.

[SolitaryThinker]

The idempotence flag is only set after both cleanup calls finish. If self.worker.shutdown() raises, or if the parent sends SIGTERM while shutdown_compile_workers() is still waiting (the exact timeout path here raises SystemExit from worker_main's signal handler), this call exits with _shutdown_complete == False. worker_main then reaches its finally block and invokes shutdown() again, repeating the underlying worker cleanup; in the first case the compiler pool cleanup is skipped as well. I reproduced the SIGTERM shape with a probe where compile cleanup raises SystemExit: worker.shutdown() and compile cleanup were each called twice. Please transition to a separate shutdown_started state at entry (not only complete at success), keep compiler cleanup best-effort in a finally, and add a regression for interrupted/failed cleanup.