Tracking Issue for windows_process_extensions_main_thread_handle

[nico-abram]

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

// std::process

pub trait ChildExt: Sealed {
    #[unstable(feature = "windows_process_extensions_main_thread_handle", issue = "96723")]
    fn main_thread_handle(&self) -> RawHandle;
}

Steps / History

• Implementation: Expose process windows_process_extensions_main_thread_handle on Windows #96725
• Final comment period (FCP)
• Stabilization PR

[TYPEmber]

how about make main_thread_handle as Option<Handle>?

Except creating a child process, it is difficult for us to get the main_thread_handle of another process. If we make this item Option, we could extend struct Process's use case. Such as building a process manager, which holds some process's handle without main_thread_handle.

[nico-abram]

I don't think the Process struct defined in library/std/src/sys/windows/process.rs is part of the public API. And the fields are private, and only used for std::process::Child. As far as I understand, if/when APIs which deal with non-child processes are added to std the change you mentioned can be done internally, and it should be tranparent to code outside std.

[madsmtm]

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.