Named pipe connection code needs to not busy wait

[jaredpar]

The API NamedPipeClientStream::Connect has a busy wait algorithm with no back off semantics. This can create a huge lag in our standard server compilation scenario on a single core machine:

1. csc spins up a compiler server instance.
2. Moves to NamedPipeClientStream::Connect.
3. Server process begins starting up.

Unfortunately on a single core machine the Connect loop can dominate and cause the server to take ~14 seconds to actually start up and process the connection. Need to call Connect with a small timeout here and do a SpinWait to make it less busy.

[agocke]

Perhaps we should also consider a reflection call to the async API if it's available? When we kick 4.5 support to the curb we can then just always use the async API.

We'll still need the SpinWait for people really running on .NET 4.5, but this may be a bit more future-proof.

[shmao]

NamedPipeClientStream.ConnectAsync probably wouldn't help. The implementation of the Async API is quite similar to the Sync one. I think it might have the same issue.

[davidfowl]

/cc @stephentoub

[robertmclaws]

Hey, all! Just wanted to pop in with a little background info. This is related to an issue running Roslyn in ASP.NET on Azure Websites for C# 6.0 features. Had to uninstall the package from production because that 14 second spin-up was affecting our users. Someone else experienced the same issue and posted about it on StackOverflow.

Thanks for your help, and looking forward to a fix! :)

[stephentoub]

Need to call Connect with a small timeout here and do a SpinWait to make it less busy.

Note that NamedPipeClientStream in corefx already uses SpinWait:
https://github.com/dotnet/corefx/blob/master/src/System.IO.Pipes/src/System/IO/Pipes/NamedPipeClientStream.cs#L172
which uses a mixture of Thread.SpinWait, Thread.Yield, and Thread.Sleep to avoid these kinds of issues. That fix has not yet been ported back to the .NET Framework, however:
http://referencesource.microsoft.com/#System.Core/System/IO/Pipes/Pipe.cs,1192
I would expect this Roslyn issue to manifest on the .NET Framework but not on .NET Core... if that's not the case, please let us know.

cc: @ianhays

[davidfowl]

I would expect this Roslyn issue to manifest on the .NET Framework but not on .NET Core... if that's not the case, please let us know.

It's on .NET Framework, not .NET Core.

[jaredpar]

Indeed it's on .NET Framework. Even if we ported the fix there it wouldn't help because this particular scenario, Roslyn + legacy ASP.Net pages, must work on .NET 4.5.

[agocke]

Closed by #11709