diff options
| author | Brad King <brad.king@kitware.com> | 2025-11-09 14:07:01 (GMT) |
|---|---|---|
| committer | Brad King <brad.king@kitware.com> | 2025-11-09 14:13:43 (GMT) |
| commit | 6ec2c51f0c30f51c078468d92a1b7d9c478fb2cc (patch) | |
| tree | 305e592616e68c25d1838f8da68ff795917077e6 /Tests/RunCMake/FindPython/FindPythonScript.cmake | |
| parent | b4cdd8aab54c1e41cb91290c091a70a8df45b5db (diff) | |
| download | CMake-6ec2c51f0c30f51c078468d92a1b7d9c478fb2cc.zip CMake-6ec2c51f0c30f51c078468d92a1b7d9c478fb2cc.tar.gz CMake-6ec2c51f0c30f51c078468d92a1b7d9c478fb2cc.tar.bz2 | |
execute_process: Restore support for short timeouts
Since commit 5420639a8d (cmExecuteProcessCommand: Replace cmsysProcess
with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8) we've
occasionally observed immediate timeouts on processes that take longer
than the timeout to start, even though we only start the timer after the
child processes start. The problem is that:
* `uv_loop_init` initializes `uv_loop_t`'s cached "now" time.
* Starting processes takes time but does not update the "now" time.
* `uv_timer_start` computes expiry relative the cached "now" time,
so short timers may be expired as soon as they are started.
* `uv_run` invokes expired timer callbacks before polling for I/O
or process completion, so we "timeout" immediately.
Fix this by updating the cached "now" time via `uv_update_time` just
before starting timers. This is needed only for timers that start
before the `uv_run` event loop. Update our `uv_timer_ptr` wrapper
to make all callers consider the choice when calling `start()`.
Diffstat (limited to 'Tests/RunCMake/FindPython/FindPythonScript.cmake')
0 files changed, 0 insertions, 0 deletions
