mirror of
https://github.com/safishamsi/graphify.git
synced 2026-08-29 09:46:43 +00:00
Souptik Chakraborty
556e615cc6
`_extract_parallel` spawned a ProcessPoolExecutor whenever there were at least _PARALLEL_THRESHOLD (20) uncached files, even when the resolved worker count was 1. A one-worker pool buys no parallelism: it still pays a process spawn plus an IPC round trip per file, and it is the one residual case where the parent's rebuild watchdog (os._exit) can orphan a worker that is mid-task. The Windows post-commit hook exports GRAPHIFY_MAX_WORKERS=1, so this was the default there for any rebuild touching 20+ uncached files. Gate the pool on the resolved worker count -- after the GRAPHIFY_MAX_WORKERS override and the win32/floor clamps -- and return False when it is 1. That reuses the existing contract: the caller already falls back to `_extract_sequential` in-process when `_extract_parallel` returns False. Tests: no pool is constructed with GRAPHIFY_MAX_WORKERS=1 and 25 uncached files, and a multi-worker run still takes the pool path. Only item 2 of #2173 is addressed here. Item 1 (the `graphify watch` rebuild timeout) needs a maintainer decision first: `watch()` currently arms no timeout at all on any platform -- there is no signal.SIGALRM branch in graphify/watch.py to add an `else` to -- so applying the hook's shape means adding a watchdog that os._exit(1)s a long-running foreground watcher on a slow-but-healthy rebuild. That is a behaviour change rather than a Windows-compat fix, so it is left out of this PR.