start_diffusion_training freed resident GPU models and only then called service.start(config), which is where is_active() first flips true. During that free-then-spawn window a concurrent /images/load or /video/load saw training as inactive, passed its training guard, acquired the GPU, and began a background load, so the trainer and that pipeline both allocated VRAM. Add reserve()/unreserve() to the training service (is_active() also reports the reservation) and reserve BEFORE the free, in a try/finally so a failed start rolls the reservation back. An overlapping load's guard now refuses during the window. Regression tests: the route reserves before the free (and the free sees an active service), and the service reservation marks active then rolls back. |
||
|---|---|---|
| .. | ||
| assets | ||
| auth | ||
| core | ||
| hub | ||
| loggers | ||
| models | ||
| plugins | ||
| requirements | ||
| routes | ||
| state | ||
| storage | ||
| tests | ||
| utils | ||
| __init__.py | ||
| _platform_compat.py | ||
| cloudflare_tunnel.py | ||
| colab.py | ||
| main.py | ||
| run.py | ||
| startup_banner.py | ||