[API Proposal]: Process ``HasStarted`` property

[alastairlundy]

Background and motivation

Trying to figure out programatically if a specific Process in .NET has started is difficult/next to impossible right now without having an exception being thrown or avoiding the exception by looking specifically for it with a Try/Catch, or potentially some other convoluted way.

It would be nice to not have to rely on a Try/Catch to spot an Invalid Operation Exception when accessing Process.StartTime to figure out if a Process has started.

Here's the code I use as a workaround right now:

    internal static bool HasStarted(this Process process)
    {
        try
        {
            return process.StartTime.ToUniversalTime() <= DateTime.UtcNow;
        }
        catch(InvalidOperationException)
        {
            return false;
        }
    }

The code works because the StartTime property will throw an exception which is caught if the Process hasn't started, and will evaluate to true if it has started. It would be nice to not have to rely on this.

API Proposal

namespace System.Diagnostics;

public class Process : Component, IDisposable
{
    public bool HasStarted { get; }
}

API Usage

Here's an example for setting Processor Affinity - The ProcessorAffinity property requires the Process to be started but not exited in order to be set without an exception being thrown.

if(process.HasStarted && !process.HasExited)
{
  // Do something that requires the Process to have been started but not yet exited.
        if (OperatingSystem.IsWindows() || OperatingSystem.IsLinux())
        {
            if (processorAffinity is not null)
            {
                process.ProcessorAffinity = processorAffinity;
            }
        }
}

Alternative Designs

One alternative could be to allow all Process properties to be set before being started but this may be more work than creating a HasStarted property.

Another alternative could be publicly exposing Process State via the API but this would be less helpful.

e.g.

namespace System.Diagnostics;

public class Process : Component, IDisposable
{
    public Process.State State { get; }
}

Risks

No response

[Clockwork-Muse]

Here's an example for setting Processor Affinity - The ProcessorAffinity property requires the Process to be started but not exited in order to be set without an exception being thrown.

This property can be set by the running process itself (at least, I'm seeing examples showing that to be the case).

That said...

Trying to figure out programatically if a specific Process in .NET has started is difficult/next to impossible right now without having an exception being thrown or avoiding the exception by looking specifically for it with a Try/Catch, or potentially some other convoluted way.

... The "traditional" way to handle this concern stems from something else important - in almost all cases you need some sort of communication channel between the parent and child process; to pass data back and forth, get process health (more than just "crashed"), and more. This channel then provides a ready-made way to do this check, and importantly, provide a more reliable and usable status; that is, readiness of the process to handle whatever data you would send it. This covers cases where the process might report "started" but is otherwise not running in some fashion.

Technically this is slightly more complicated, but the process does expose stdin/stdout, which can take you pretty far in many cases.

[alastairlundy]

This property can be set by the running process itself (at least, I'm seeing examples showing that to be the case).

Yes but as mentioned setting it will throw an exception if the Process hasn't started or has exited. Just checking to see if the Process HasExited is false isn't enough to prevent that code from running if the Process hasn't started, thus causing an exception to be thrown since ProcessorAffinity must be set to a running process.

... The "traditional" way to handle this concern stems from something else important - in almost all cases you need some sort of communication channel between the parent and child process; to pass data back and forth, get process health (more than just "crashed"), and more. This channel then provides a ready-made way to do this check, and importantly, provide a more reliable and usable status; that is, readiness of the process to handle whatever data you would send it. This covers cases where the process might report "started" but is otherwise not running in some fashion.

Could you elaborate on this and/or provide an example of what you mean? I don't see how channels would help with the.

Assuming that there is a way channels would help with this, it feels like an unnecessarily complicated way of solving the issue. Surely it would be easier for Process objects to provide more meaningful state information themselves?

Technically this is slightly more complicated, but the process does expose stdin/stdout, which can take you pretty far in many cases.

Do you mean by trying to read from the Standard Output to see if it has any data?

[Clockwork-Muse]

Could you elaborate on this and/or provide an example of what you mean? I don't see how channels would help with the.

Not "channel" as in System.Threading.Channels specifically, but "channel" as in "Some path for communication".

There are multiple options for what this might be; it could be a named pipe, socket, files written to disk, or...

Do you mean by trying to read from the Standard Output to see if it has any data?

Essentially, yes.

The potential "problem" is that standard out is often used for logging, so at scale/for more complicated communication needs normally a separate communication path is used.

But for simple stuff, just have something parse the messages until some "I'm done setting up and ready to process data!" message is written to standard out.