Add ability to spawn Windows process with Proc Thread Attributes | Take 2

[michaelvanstraten]

This is the second attempt to merge pull request #88193 into the standard library.

This PR implements the ability to add arbitrary attributes to a command on Windows targets using a new raw_attribute method on the CommandExt trait.

@TyPR124 and my main motivation behind adding this feature is to enable the support of pseudo terminals in the std library, but there are many more applications. A good starting point to get into this topic is to head over to the Win32 API documentation.

[rustbot]

r? @ChrisDenton

(rustbot has picked a reviewer for you, use r? to override)

[michaelvanstraten]

Okay the tracking issue has been created under #114854.

[michaelvanstraten]

Before bringing this to review I would like to revisit the conversation about the parallels between proc attributes and thread attributes.

Since both support the attachment of attributes and the api is the same for both I think that the current implementation of this PR should be changed.

I believe we can make this work with threads by ether:

• creating a ProcThreadAttribute trait implemented for std::thread::Builder and std::process::Command
  or
• putting the implementation of the creation of ProcThreadAttributeList in a struct that both std::tread::Builder and std::process::Command can access

I think the later is more practical since windows states that a ProcThreadAttributeList can be used to crate multiple process/threads.

Second thing:

Removing the Pin since it doesn’t prevent use from moving the data anyway. I think a Box would be just fine.

[ChrisDenton]

putting the implementation of the creation of ProcThreadAttributeList in a struct that both std::thread::Builder and std::process::Command can access

I would tend to agree this is the better option but I think revisiting the old API would require a new ACPppropriate. It could explain the proposed public API for both Command and thread::Builder.

Alternatively we could start with merging what we have here and leave discussion on an improved API to the tracking issue.

[michaelvanstraten]

@ChrisDenton I didn't exactly get what you were saying should I open a new ACP or not?

For now, I wouldn't change the public interface, except maybe the documentation.

[ChrisDenton]

If you're not changing the API from the original then I think it's fine to go ahead with this.

[ChrisDenton]

This is looking good to me but the docs could have a bit more explanation.

[ChrisDenton]

The lines in this file are sorted by doing a lowercase comparison. Hopefully this sorting will be better automated in the future.

[michaelvanstraten]

@rustbot label -S-waiting-on-author +S-waiting-on-review

[michaelvanstraten]

Somebody has to test this on a windows target, im only on Unix so i can't test this.

[klensy]

This can be MaybeUninit, but it's optional. Maybe adding fixme?

[michaelvanstraten]

Whats the benifit of the MaybeUninit?

[TyPR124]

MaybeUninit would allow the allocation to be faster, since we'd skip writing all 0's. Since we never directly read the memory, and the Win32 API is just fine with this memory being uninitialized (see example code here near the bottom of that page), we can do the same.

[michaelvanstraten]

Thank you for the clarification

[michaelvanstraten]

Happy with the current impl?

[ChrisDenton]

These kill calls will not be run if the test panics. This will result in the test process never exiting.

[michaelvanstraten]

Currently not on my pc but I will fix that as soon as I get back.

[michaelvanstraten]

Okay, in 0e84161 I prevented the test from leaking the process if the spawn of the child fails. But the call to wnic could still fail if it doesn't find the process_id or the binary simply doesn't exist.

[michaelvanstraten]

I found the following snippet on Stack Overflow, it locates a parent process using the win32 API:

#include <stdio.h>
#include <windows.h>
#include <tlhelp32.h>

int main(int argc, char *argv[]) 
{
    int pid = -1;
    HANDLE h = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    PROCESSENTRY32 pe = { 0 };
    pe.dwSize = sizeof(PROCESSENTRY32);

    //assume first arg is the PID to get the PPID for, or use own PID
    if (argc > 1) {
        pid = atoi(argv[1]);
    } else {
        pid = GetCurrentProcessId();
    }

    if( Process32First(h, &pe)) {
        do {
            if (pe.th32ProcessID == pid) {
                printf("PID: %i; PPID: %i\n", pid, pe.th32ParentProcessID);
            }
        } while( Process32Next(h, &pe));
    }

    CloseHandle(h);
}

Maybe this could be more stable?

All functions are loaded through Kernel32.dll and are available since Windows XP and Windows Server 2003.

[michaelvanstraten]

@TyPR124 what are your thoughts?

[ChrisDenton]

The easiest way to ensure a process is killed would be to wrap the spawned Child in a tuple struct that implements drop. E.g.:

struct Process(crate::process::Child);
impl Drop for Process {
    fn drop(&mut self) {
        let _ = self.0.kill();
    }
}
let parent = Process(Command::new("cmd.exe").spawn().unwrap());

[ChrisDenton]

I do think it's also useful to also use the winapi directly instead of wmic though. The wmic utility is marked as deprecated.

[michaelvanstraten]

Okay, I will try to test the win32 API version on a windows target as soon as possible.

[michaelvanstraten]

Okay, this is a mock-up implementation for now. If this is unwanted, I will revert the change tomorrow.

[ChrisDenton]

Ok, this is looking ready to merge. Just one small thing then please squish your commits when you're ready.

You might also want to update your opening post to reflect the current state of this PR.

[michaelvanstraten]

Okay, I will squash all commit now, or @TyPR124 should I keep yours at the base?

[ChrisDenton]

Squish your commits but make sure that the commit message has Co-authored-by: lines at the end to give proper credit

[michaelvanstraten]

@ChrisDenton Is there anything left for me to do ?

[ChrisDenton]

Nope, just waiting on me to take a final look at the code. Which I've now done, so let's see if CI is happy with it.

@bors r+

[bors]

📌 Commit edefa8b has been approved by ChrisDenton

It is now in the queue for this repository.

[bors]

⌛ Testing commit edefa8b with merge 9847c64...

[bors]

☀️ Test successful - checks-actions
Approved by: ChrisDenton
Pushing 9847c64 to master...

[rust-timer]

Finished benchmarking commit (9847c64): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.9%	[-2.2%, -1.7%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.9%	[-2.2%, -1.7%]	2

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.8%	[-2.1%, -1.5%]	2
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 630.025s -> 630.448s (0.07%)
Artifact size: 316.26 MiB -> 316.23 MiB (-0.01%)