SerialPort.Unix: use UnixHandleAsyncContext.

[tmds]

This reduces read latency and CPU usage by replacing the poll-loop with epoll/kevent.

To access the UnixHandleAsyncContext from CoreLib, UnsafeAccessorAttribute is used.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-io-ports
See info in area-owners.md if you want to be subscribed.

[tmds]

The SerialPort.Tests are passing on my machine, but that is probably not covering much since I don't have a serial port...

I suspect the Tests themselves will need some updates too which is not yet included in this PR. I can look into this further if there is some interest in this change.

To access the UnixHandleAsyncContext from CoreLib, UnsafeAccessorAttribute is used.

I'm not sure if this is considered acceptable.

The SerialPort implementation was already part of #127228. To make this PR I only had to adjust it for using the UnixHandleAsyncContext that was added to CoreLib.

[jkotas]

System.IO.Ports is standalone nuget package. It is not ok to depend on internal APIs from standalone nuget package. This can proceed only once the APIs are approved and public.

[tmds]

System.IO.Ports is standalone nuget package. It is not ok to depend on internal APIs from standalone nuget package. This can proceed only once the APIs are approved and public.

I assumed there to be such a limitation, though I don't understand what drives it. Is it technical? Or is it a policy?
I would assume that a net12.0 target could use the APIs (even if not public) from .NET 12?

[jkotas]

.NET 12 target shipping in 12.0 nuget package is expected to work on top of .NET 13+ runtime. It means that we would not be able to change the internal APIs and they would become de-facto public without proper process.

[tmds]

Got it.

I didn't want the effort I put into making SerialPort work on top of epoll in #127228 go to waste/stale which is why I created this PR. SerialPort has some specific challenges due to its DataReceived event and the ReceivedBytesThreshold property.

There is some work to be done still in the Tests project too. I'll mark the PR as draft.

[tmds]

@dotnet/area-system-io-ports the main issues this is fixing are: #45635, #2379, and #113889.

There is extra work in API approval for UnixHandleAsyncContext. I previously had feedback from @rzikm and @liveans the API is near a proposable shape: #47631 (comment).

[jkotas]

There is extra work in API approval for UnixHandleAsyncContext. I previously had feedback from @rzikm and @liveans the API is near a proposable shape: #47631 (comment) .

We are planning to focus on improving threadpool performance in .NET 12 (cc @VSadov).

I would like to see an investigation to be done about what can be done to improve performance now that we have both threadpool in corelib. I do not think that having the two independent threadpools in Corelib that do not cooperate much is where we want to be. I expect that the API shape is likely to change as a result of this investigation.

[tmds]

I would like to see an investigation to be done about what can be done to improve performance now that we have both threadpool in corelib. I do not think that having the two independent threadpools in Corelib that do not cooperate much is where we want to be. I expect that the API shape is likely to change as a result of this investigation.

I'm interested to see where this will go. I don't think of UnixHandleAsyncContext as a ThreadPool. I consider it an abstraction that delivers the readiness notification. It requires a thread because that is what epoll/kevent need.