Revert "Use socketpair to implement Process.Start redirection" (#47461)

[eiriktsarpalis]

Backport of #47461 and #47643 to release/5.0, fixing #46469.

Customer Impact

Multiple customers reporting a Linux regression introduced in .NET 5: if a .NET process spawns a child process with redirected IO, the child process will fail with ENXIO if it attempts to open the /dev/std* file paths. There are no known workarounds other than changing the code of the child process.

Testing

Added a unit test that validates the regressed behaviour.

Risk

Low. This reverts to the IO redirection implementation used in previous .NET Core versions. The revert does not change functional behaviour but could have impact on scalability and responsiveness, per the comments in #47644 (comment). The change is a clean revert, incorporating a test that verifies the regression.

[ghost]

Tagging subscribers to this area:
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #47461 to release/5.0, fixing #46469.

Customer Impact

Multiple customers reporting a Linux regression introduced in .NET 5: if a .NET process spawns a child process with redirected IO, the child process will fail with ENXIO if it attempts to open the /dev/std* file paths. There are no known workarounds other than changing the code of the child process.

Testing

Added a unit test that validates the regressed behaviour.

Risk

Low. This reverts to the IO redirection implementation used in previous .NET Core versions.

Author:	eiriktsarpalis
Assignees:	eiriktsarpalis
Labels:	Servicing-consider, area-System.Diagnostics.Process
Milestone:	5.0.x

[danmoseley]

@eiriktsarpalis could you please note in the template what is lost by returning to the old behavior -- presumably there was a reason for the original change -- will we break anyone that now depends on it.

[stephentoub]

could you please note in the template what is lost by returning to the old behavior -- presumably there was a reason for the original change -- will we break anyone that now depends on it.

Prior to that original change, "async" operations performed on a Process' stdin/stdout/stderr stream would a) be async-over-sync (meaning they'd actually be done with sync operations that block thread pool threads) and b) wouldn't be cancelable. The change made it so that async operations on such streams were truly async and were cancelable.

[danmoseley]

The change made it so that async operations on such streams were truly async and were cancelable.

OK so with this revert, nothing will break? they will simply not cancel successfully when requested to.

[stephentoub]

they will simply not cancel successfully when requested to

Essentially. Cancellation may not take effect, and thread pool threads may be blocked. The former impacts responsiveness, and the latter impacts scalability.

[danmoseley]

Another thing you might mention is whether this was a clean revert or needed some hand merging. The latter adds risk.

[adamsitnik]

LGTM, thank you @eiriktsarpalis