Tracking Issue for windows_process_extensions_main_thread_handle #96723
Comments
Expose process windows_process_extensions_main_thread_handle on Windows ~~I did not find any tests in https://github.com/rust-lang/rust/blob/7d3e03666a93bd2b0f78b3933f9305832af771a5/library/std/src/sys/windows/process/tests.rs that actually launch processes, so I haven't added tests for this.~~ I ran the following locally, to check that it works as expected: ```rs #![feature(windows_process_extensions_main_thread_handle)] fn main() { use std::os::windows::process::{ChildExt, CommandExt}; const CREATE_SUSPENDED: u32 = 0x00000004; let proc = std::process::Command::new("cmd") .args(["/C", "echo hello"]) .creation_flags(CREATE_SUSPENDED) .spawn() .unwrap(); extern "system" { fn ResumeThread(_: *mut std::ffi::c_void) -> u32; } unsafe { ResumeThread(proc.main_thread_handle()); } let output = proc.wait_with_output().unwrap(); let str_output = std::str::from_utf8(&output.stdout[..]).unwrap(); println!("{}", str_output); } ``` Without the feature attribute it wouldn't compile, and commenting the `ResumeThread` line makes it hang forever, showing that it works. Trakcing issue rust-lang#96723
Expose process windows_process_extensions_main_thread_handle on Windows ~~I did not find any tests in https://github.com/rust-lang/rust/blob/7d3e03666a93bd2b0f78b3933f9305832af771a5/library/std/src/sys/windows/process/tests.rs that actually launch processes, so I haven't added tests for this.~~ I ran the following locally, to check that it works as expected: ```rs #![feature(windows_process_extensions_main_thread_handle)] fn main() { use std::os::windows::process::{ChildExt, CommandExt}; const CREATE_SUSPENDED: u32 = 0x00000004; let proc = std::process::Command::new("cmd") .args(["/C", "echo hello"]) .creation_flags(CREATE_SUSPENDED) .spawn() .unwrap(); extern "system" { fn ResumeThread(_: *mut std::ffi::c_void) -> u32; } unsafe { ResumeThread(proc.main_thread_handle()); } let output = proc.wait_with_output().unwrap(); let str_output = std::str::from_utf8(&output.stdout[..]).unwrap(); println!("{}", str_output); } ``` Without the feature attribute it wouldn't compile, and commenting the `ResumeThread` line makes it hang forever, showing that it works. Trakcing issue rust-lang/rust#96723
|
how about make Except creating a child process, it is difficult for us to get the |
|
I don't think the Process struct defined in |
|
Windows documentation generally describe this as the "primary" thread (see e.g. here), so a consideration would be to rename this method to reflect that? Then again, there is precedence for the name "main thread" on macOS (and a few other BSDs), and in Rust's own documentation, so maybe the current name is fine. |
Summary: Change `resume_process` implementation to get main thread handle through [unstable api](rust-lang/rust#96723) in std::process::Child and not use `CreateToolhelp32Snapshot`, because iteration over treads cause performance issue. Reviewed By: stepancheg Differential Revision: D53472748 fbshipit-source-id: 2589ade412363cf96f5fcb2f896517d4650d0235
Feature gate:
#![feature(windows_process_extensions_main_thread_handle)]This is a tracking issue for a new
main_thread_handle(&self)function on a new ChildExt trait for windows.The winapi function used to create a process on windows returns a structure that has both a main thread handle and a process handle. std currently discards the thread handle, but that handle can be useful when resuming a process that was created as suspended since that is usually done with ResumeThread. Finding that thread from the process handle can be a bit convoluted, so it'd be nice if std exposed it on a windows-specific extension trait.
Public API
Steps / History
The text was updated successfully, but these errors were encountered: