[mono] Portable threadpool does not support async IO eg ThreadPoolBoundHandle on Windows

[MaximLipnin]

A lot of System.IO.Pipes.Tests fail with System.PlatformNotSupportedException : This API is specific to the way in which Windows handles asynchronous I/O, and is not supported on this platform. on windows.
The example of the output:

System.IO.Pipes.Tests.NamedPipeTest_Simple_ServerInOutRead_ClientInOutWrite.OperationsOnDisconnectedClient [FAIL]
System.PlatformNotSupportedException : This API is specific to the way in which Windows handles asynchronous I/O, and is not supported on this platform.
Stack Trace:
    _\src\libraries\System.Private.CoreLib\src\System\Threading\ThreadPoolBoundHandle.PlatformNotSupported.cs(25,0): at System.Threading.ThreadPoolBoundHandle.BindHandle(SafeHandle handle)
    _\src\libraries\System.IO.Pipes\src\System\IO\Pipes\PipeStream.Windows.cs(46,0): at System.IO.Pipes.PipeStream.InitializeAsyncHandle(SafePipeHandle handle)
    _\src\libraries\System.IO.Pipes\src\System\IO\Pipes\PipeStream.cs(101,0): at System.IO.Pipes.PipeStream.InitializeHandle(SafePipeHandle handle, Boolean isExposed, Boolean isAsync)
    _\src\libraries\System.IO.Pipes\src\System\IO\Pipes\NamedPipeServerStream.Windows.cs(122,0): at System.IO.Pipes.NamedPipeServerStream.Create(String pipeName, PipeDirection direction, Int32 maxNumberOfServerInstances, PipeTransmissionMode transmissionMode, PipeOptions options, Int32 inBufferSize, Int32 outBufferSize, PipeSecurity pipeSecurity, HandleInheritability inheritability, PipeAccessRights additionalAccessRights)
    _\src\libraries\System.IO.Pipes\src\System\IO\Pipes\NamedPipeServerStream.Windows.cs(49,0): at System.IO.Pipes.NamedPipeServerStream.Create(String pipeName, PipeDirection direction, Int32 maxNumberOfServerInstances, PipeTransmissionMode transmissionMode, PipeOptions options, Int32 inBufferSize, Int32 outBufferSize, HandleInheritability inheritability)
    _\src\libraries\System.IO.Pipes\src\System\IO\Pipes\NamedPipeServerStream.cs(85,0): at System.IO.Pipes.NamedPipeServerStream..ctor(String pipeName, PipeDirection direction, Int32 maxNumberOfServerInstances, PipeTransmissionMode transmissionMode, PipeOptions options, Int32 inBufferSize, Int32 outBufferSize, HandleInheritability inheritability)
    _\src\libraries\System.IO.Pipes\src\System\IO\Pipes\NamedPipeServerStream.cs(41,0): at System.IO.Pipes.NamedPipeServerStream..ctor(String pipeName, PipeDirection direction, Int32 maxNumberOfServerInstances, PipeTransmissionMode transmissionMode, PipeOptions options)
    _\src\libraries\System.IO.Pipes\tests\NamedPipeTests\NamedPipeTest.Simple.cs(761,0): at System.IO.Pipes.Tests.NamedPipeTest_Simple_ServerInOutRead_ClientInOutWrite.CreateNamedPipePair(PipeOptions serverOptions, PipeOptions clientOptions)
    _\src\libraries\System.IO.Pipes\tests\NamedPipeTests\NamedPipeTestBase.cs(42,0): at System.IO.Pipes.Tests.NamedPipeTestBase.CreateNamedPipePair()
    _\src\libraries\System.IO.Pipes\tests\NamedPipeTests\NamedPipeTest.Simple.cs(310,0): at System.IO.Pipes.Tests.NamedPipeTest_Simple.OperationsOnDisconnectedClient()

The whole namespace will be marked with ActiveIssue in #32592

[ghost]

Tagging @carlossanlop as an area owner

[danmoseley]

@MaximLipnin this is because Mono corelib is not built with <FeaturePortableThreadPool>true</FeaturePortableThreadPool>. Should it be?
cc @kouvel

[MaximLipnin]

@danmosemsft Thanks for clarification, but please correct me if I'm wrong - a quick search shows that this flag is activated in Mono's SPC

[kouvel]

The portable thread pool implementation currently doesn't support BindHandle. I guess that Mono would inherit the PNSE implementation here:

runtime/src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems

Lines 1807 to 1810 in 893882f

	<ItemGroup Condition="'$(FeaturePortableThreadPool)' == 'true'">
	<Compile Include="$(MSBuildThisFileDirectory)System\AppContextConfigHelper.cs" />
	<Compile Include="$(MSBuildThisFileDirectory)System\Threading\ThreadPool.Portable.cs" />
	<Compile Include="$(MSBuildThisFileDirectory)System\Threading\ThreadPoolBoundHandle.PlatformNotSupported.cs" />

I guess IO completion stuff may need to be added to the portable implementation on Windows to make BindHandle work there, I don't know if Mono has an alternative implementation it can fork to easily at the moment for those. Probably would be best to add that to the portable implementation.

[marek-safar]

<FeaturePortableThreadPool>true</FeaturePortableThreadPool>

This is correct.

Could the tests be guarded with IsBindHandleSupported instead of Windows only or is the BindHandle support something your team can fix?

I know @jkotas would like to use portable TP for CoreCLR too and this could be a blocker.

[jkotas]

@jkotas would like to use portable TP for CoreCLR too and this could be a blocker.

Adding implementation for IO completion stuff (ie BindHandle and friends) is one of the things that will need to be fixed to fully switch to portable TP for CoreCLR on Windows.

To understand the priority: Is Mono going to ship as officially supported on Windows for .NET 5?

[marek-safar]

It's not high on our priority list to support IO completion stuff anywhere (including Windows)

[danmoseley]

To understand the priority: Is Mono going to ship as officially supported on Windows for .NET 5?

I am interested in this too as it helps us understand what to do about these mono-on-Windows bugs. My assumption is that there is value in getting this test pass clean, regardless.

cc @steveisok

[ericstj]

Libraries rely on this API in order to create an IO completion ports. This is necessary for any of our async IO implementations to work on Windows. I agree with @jkotas here: if you care about running mono on Windows I wouldn't leave this as throwing.

[jkotas]

One option to consider is to use Windows OS built-in threadpool that comes with IO completion port support. It is what CoreRT does: https://github.com/dotnet/corert/blob/master/src/System.Private.CoreLib/src/System/Threading/ThreadPool.Windows.cs . It comes with trade-offs, e.g. Windows OS built-in threadpool has different heuristics.

[SamMonoRT]

Moving to 7.0.0

[lateralusX]

I guess IO completion stuff may need to be added to the portable implementation on Windows to make BindHandle work there, I don't know if Mono has an alternative implementation it can fork to easily at the moment for those. Probably would be best to add that to the portable implementation.

@kouvel, any plans to actually implement support in portable thread pool so we can get this working on Mono?

[kouvel]

any plans to actually implement support in portable thread pool so we can get this working on Mono?

Yes I'm planning on adding support for BindHandle in the portable thread pool soon.