t.stac: fixed issue with download and import asset potentially overwhelming network.#1641
t.stac: fixed issue with download and import asset potentially overwhelming network.#1641cwhite911 wants to merge 8 commits into
Conversation
|
The test is currently failing, but I didn't check whether that is related to this PR or not: |
| execute_import_grass_raster() | ||
|
|
||
| def _run(pbar=None): | ||
| with ProcessPoolExecutor(max_workers=nprocs) as executor: |
There was a problem hiding this comment.
Claude (see below) doesn't think ProcessPoolExceutor is a good choice, what was the reason for the switch?
Why ProcessPoolExecutor? The actual work — r.import — is already spawned as a subprocess by gs.parse_command, so the task is I/O-bound from Python's perspective and the GIL is released during the subprocess wait. ThreadPoolExecutor was the appropriate choice. Switching to processes
adds pickling + process-spawn overhead (especially on macOS/Windows where spawn re-imports staclib and the full pygrass stack) with no parallelism gain. Both real fixes — the cap of 8 and the GDAL env vars — work identically with threads. Unless there's a concrete reason (a GRASS
fork-safety issue?), I'd keep ThreadPoolExecutor and drop the manual sliding-window machinery entirely; executor.map already bounds in-flight work to max_workers.
There was a problem hiding this comment.
ProcessPoolExecutor gives each worker its own env and its own GRASS session, which eliminates race conditions WIND_OVERRIDE, GIS_LOCK, and region state.
There was a problem hiding this comment.
Each r.import has its own process, so I don't see how this applies. Concurrent r.import should work, if not, that's a bug.
Fixes bug with parallel download and import potentially overwhelming STAC API with requests if nproc is set too high.