Summary
When all-smi is embedded as a library in a Windows GUI application (one built with #![windows_subsystem = "windows"], so it has no attached console), a console window flashes briefly whenever all-smi spawns a child process. The reporter sees it on startup via AllSmi::new(), and because all-smi shells out to vendor tools on every collection, the flash can recur during ongoing monitoring, not only at startup. The fix is to set the Windows CREATE_NO_WINDOW process creation flag on the child processes all-smi spawns.
Background
On Windows, spawning a console subprocess from a GUI (windowless) process causes the OS to allocate a console for the child, which appears as a brief flashing window. Rust's std::process::Command does not set any creation flags by default, so every child inherits this behavior unless CREATE_NO_WINDOW (0x08000000) is supplied via std::os::windows::process::CommandExt::creation_flags.
all-smi spawns vendor CLIs (for example nvidia-smi) to detect and query hardware. The central spawn helper is run_command_with_timeout in src/utils/command_timeout.rs:91, which builds a bare Command (line 97) with no creation flags. The NVIDIA reader reaches it through this path: src/device/readers/nvidia.rs invokes nvidia-smi via that helper (see the fallback paths around lines 769 and 854). Other readers and utilities spawn processes directly with Command::new as well (for example src/utils/system.rs, src/device/process_list.rs, src/device/readers/gaudi.rs, src/device/readers/google_tpu.rs). A repository-wide search finds no use of creation_flags or CREATE_NO_WINDOW anywhere, so no spawn site currently suppresses the console window.
Proposed Solution
Apply the CREATE_NO_WINDOW creation flag to every child process all-smi spawns on Windows. Centralizing this in the shared spawn helper covers the common path; the remaining direct Command::new call sites need the same treatment so no detection path leaks a console window.
A Windows-only extension trait or a small wrapper helper keeps the platform code isolated, for example:
#[cfg(windows)]
use std::os::windows::process::CommandExt;
#[cfg(windows)]
const CREATE_NO_WINDOW: u32 = 0x0800_0000;
#[cfg(windows)]
cmd.creation_flags(CREATE_NO_WINDOW);
guarded so non-Windows builds are unaffected.
Implementation Notes
- Set the flag on the
Command built in run_command_with_timeout (src/utils/command_timeout.rs:97). This covers run_command_fast_fail and every reader that routes through it, including the NVIDIA nvidia-smi paths in src/device/readers/nvidia.rs.
- Audit the direct
Command::new call sites and apply the same flag: src/utils/runtime_environment.rs, src/utils/system.rs, src/network/client.rs, src/device/readers/tpu_info_runner.rs, src/device/readers/gaudi.rs, src/device/readers/google_tpu.rs, src/device/process_list.rs, src/device/process_utils.rs, src/device/hlsmi/process.rs, src/device/cpu_linux.rs, src/device/cpu_macos.rs. A shared helper that constructs the Command would prevent future sites from regressing.
- Keep all Windows-specific code behind
#[cfg(windows)] (or #[cfg(target_os = "windows")]) so Unix and macOS builds compile unchanged. The CommandExt import and creation_flags call exist only on Windows.
- The Windows-relevant spawn paths in practice are the NVIDIA reader, the Intel GPU Windows reader, the AMD Windows reader, and the Windows CPU/temperature utilities; verify each no longer flashes a console.
Acceptance Criteria
- Building the reporter's minimal example (
#![windows_subsystem = "windows"] calling all_smi::AllSmi::new()) shows no flashing console window on startup.
- No console window flashes during subsequent metric collection on Windows GUI applications.
- Non-Windows builds (Linux, macOS) compile and behave identically, with no new warnings.
Original Suggestion
Title: [bug] Terminal window flashing when detecting gpu on Windows
When using all-smi as a library for my GUI program I have come across an issue where there is a terminal window flashing for a split second on startup. This seems to only be a problem in apps that have the console disabled.
Minimal reproducible example (Windows OS only):
#![windows_subsystem = "windows"]
fn main() {
let _smi = all_smi::AllSmi::new().unwrap();
}
Summary
When all-smi is embedded as a library in a Windows GUI application (one built with
#![windows_subsystem = "windows"], so it has no attached console), a console window flashes briefly whenever all-smi spawns a child process. The reporter sees it on startup viaAllSmi::new(), and because all-smi shells out to vendor tools on every collection, the flash can recur during ongoing monitoring, not only at startup. The fix is to set the WindowsCREATE_NO_WINDOWprocess creation flag on the child processes all-smi spawns.Background
On Windows, spawning a console subprocess from a GUI (windowless) process causes the OS to allocate a console for the child, which appears as a brief flashing window. Rust's
std::process::Commanddoes not set any creation flags by default, so every child inherits this behavior unlessCREATE_NO_WINDOW(0x08000000) is supplied viastd::os::windows::process::CommandExt::creation_flags.all-smi spawns vendor CLIs (for example
nvidia-smi) to detect and query hardware. The central spawn helper isrun_command_with_timeoutinsrc/utils/command_timeout.rs:91, which builds a bareCommand(line 97) with no creation flags. The NVIDIA reader reaches it through this path:src/device/readers/nvidia.rsinvokesnvidia-smivia that helper (see the fallback paths around lines 769 and 854). Other readers and utilities spawn processes directly withCommand::newas well (for examplesrc/utils/system.rs,src/device/process_list.rs,src/device/readers/gaudi.rs,src/device/readers/google_tpu.rs). A repository-wide search finds no use ofcreation_flagsorCREATE_NO_WINDOWanywhere, so no spawn site currently suppresses the console window.Proposed Solution
Apply the
CREATE_NO_WINDOWcreation flag to every child process all-smi spawns on Windows. Centralizing this in the shared spawn helper covers the common path; the remaining directCommand::newcall sites need the same treatment so no detection path leaks a console window.A Windows-only extension trait or a small wrapper helper keeps the platform code isolated, for example:
guarded so non-Windows builds are unaffected.
Implementation Notes
Commandbuilt inrun_command_with_timeout(src/utils/command_timeout.rs:97). This coversrun_command_fast_failand every reader that routes through it, including the NVIDIAnvidia-smipaths insrc/device/readers/nvidia.rs.Command::newcall sites and apply the same flag:src/utils/runtime_environment.rs,src/utils/system.rs,src/network/client.rs,src/device/readers/tpu_info_runner.rs,src/device/readers/gaudi.rs,src/device/readers/google_tpu.rs,src/device/process_list.rs,src/device/process_utils.rs,src/device/hlsmi/process.rs,src/device/cpu_linux.rs,src/device/cpu_macos.rs. A shared helper that constructs theCommandwould prevent future sites from regressing.#[cfg(windows)](or#[cfg(target_os = "windows")]) so Unix and macOS builds compile unchanged. TheCommandExtimport andcreation_flagscall exist only on Windows.Acceptance Criteria
#![windows_subsystem = "windows"]callingall_smi::AllSmi::new()) shows no flashing console window on startup.Original Suggestion
Title: [bug] Terminal window flashing when detecting gpu on Windows
When using all-smi as a library for my GUI program I have come across an issue where there is a terminal window flashing for a split second on startup. This seems to only be a problem in apps that have the console disabled.
Minimal reproducible example (Windows OS only):