This is robust only if you control all other process starts that may be done by the current process.

If I am reading this correctly, this will create inheritable handles in the main test process without synchronizing with other process starts and so the handles may get accidently inherited by other processes. Is this test going to be flaky because of that?

Also, do the docs need to mention all gotchas about inherited handles and how the user code is expected to deal with them? I am not sure whether this API is the best way to address the end-to-end scenario once you take all the gotchas into account.

This is robust only if you control all other process starts that may be done by the current process.

I agree, but this is true for all ways of starting processes on Windows (the standard handles always need to be inheritable).

If I am reading this correctly, this will create inheritable handles in the main test process without synchronizing with other process starts and so the handles may get accidently inherited by other processes.

Correct.

Is this test going to be flaky because of that?

All process tests are executed sequentially, so not for now.

Also, do the docs need to mention all gotchas about inherited handles and how the user code is expected to deal with them?

They don't for now (but this can be ofc fixed).

I am not sure whether this API is the best way to address the end-to-end scenario once you take all the gotchas into account.

The alternative is to let the users pass the windows process attributes (and creation flags?) via ProcessStartInfo, something that we have discussed offline a while ago that would be passed to UpdateProcThreadAttribute:

public List<(int attribute, GCHandle value, nint byteSize)> ProcessAttributes { get; set; }

But it has one major limitation: it would support only the CreateProcess sys-call. So for example if the user wanted to use CreateProcessAsUser to implement #128378, this would not work.

alternative

I think there are more alternatives. For example, we can allow user to provide a callback that receives some of the arguments prepared for the Win32 API invocation, the user provided callback combines these arguments with their custom options and invokes the Win32 APIs of their choice.

For example, we can allow user to provide a callback that receives some of the arguments prepared for the Win32 API invocation

There are few simple arguments that such callback would need to accept that would be easy to implement:

• pointer to the command line string (char*)
• pointer to new environment block (char*)
• pointer to current directory name (char*)
• handle inheritance flag (bool)
• creation flags (int)

But advanced usages like the use case described by the customer in #71595 (comment)

I'm currently using JobObjects to limit CPU time and RAM. But I'd also like to restrict file and network access.
So, I need to use CreateRestrictedToken (or simular) API with Process capturing capabilities.

would also require us to expose STARTUPINFO and STARTUPINFOEX.

Moreover, really advanced scenarios like specifying Jobs would be still very tricky to get right together with all our existing APIs. For example, to provide Jobs, we need to specify the count up-front to allocate the right size of a buffer:

The same is true for attribute count:

And some of the Windows sys-calls used for spawning processes don't support STARTUPINFOEX with lpAttributeList (CreateProcessWithTokenW docs mention STARTUPINFOEX, but they don't mention that EXTENDED_STARTUPINFO_PRESENT is not supported anyway.). So in certain situations users would need to ignore some of the input we provide (like the attribute/job list) and start a suspended process, then add the jobs, resume the process and all of that like we do here

@jkotas from my perspective asking the users to deal with handle inheritance is lesser evil compared to exposing all the Win32 contracts and trying to provide a callback that would support all scenarios.

Also the proposed ctor could work on Unix as well. As users could just somehow spawn the process, use SafeProcessHandle.Open and give us the SPH and the pipe handles.

would also require us to expose STARTUPINFO and STARTUPINFOEX

I do not think we need to expose these structures. We can prepare the stdin/stdout/stderr handles, command line, environment, take the process create lock, and leave everything else to be provided by the user. They can supply their own definition of the PInvoke and all structures that the PInvoke needs. For example, if they want to start a process with custom job settings, they can do it all on their own.

Also the proposed ctor could work on Unix as well.

I would like to see what a "done" state looks like for the long tail of process APIs features. I do not think we want to be on the feature creep path (adding an API for every niche feature somebody asks for) that we are on currently. I do not have a fundamental problem with a few more APIs if we think that the use case is common enough.