Workaround flaky ProcessName behavior during process startup #111850
Conversation
jkotas
changed the title
Reenable long Process.Name test on OSX Fixes dotnet#111460 Fixes dotnet#29330
| @@ -2294,6 +2293,10 @@ public void LongProcessNamesAreSupported() | |||
|
|
|||
| using (Process px = Process.Start(sleepCommandPathFileName, "600")) | |||
| { | |||
| // Reading of long process names is flaky during process startup and shutdown. | |||
| // Wait a bit to skip over the period where the ProcessName is not reliable. | |||
| Thread.Sleep(100); | |||
There was a problem hiding this comment.
Might it still be flaky even with a 100ms delay? Is there some way we could make it more deterministic, some callback we could subscribe to in order to be notified when moving forward is acceptable?
There was a problem hiding this comment.
The proc file system used by underlying implementation reads the target process memory to extract the command line. I do not think there is any callback that we can subscribe to in the API implementation that tells us that the relevant memory in the target process contains the right information. Atypical or misbehaving processes may not have the information available for the whole process lifetime.
It was very rare to see this test to fail before the change. I would expect that 100ms delay should be good enough to make the rare failures to go away.
If we still see the test fail intermittently after this fix, we can output something in the child process and wait for the output in the test method. Once we see the output, we can be sure that the process is up and running and the command line is available.
Reenable long Process.Name test on OSX
Fixes #111460
Fixes #29330