You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In .NET Runtime, there is some logic conditioned on QUIC support on the platform (related to HTTP3). When checking QUIC support, we load the MsQuic library into the process and check the version (and query the TLS backend type), if compatible, we set some global flag.
However, calling MsQuicOpenVersion causes some threads to be created, which increases overall resources used by .NET programs even if they end up not using QUIC at all.
Proposed solution
Initialize the threadpool(s) lazily once the first Connection or Listener is created.
Additional context
We have resorted to a temporary workaround of calling MsQuicClose and later lazily reopening the library when necessary.
The text was updated successfully, but these errors were encountered:
#3034 is already doing this, but you need to make sure not to create registrations if you don't want threads to get created. That is the "lazy" signal that you're about to do work and need threads.
@rzikm this is fixed with recent PRs, but it is delayed to registration creation. Not connection/listener. Please update .NET to consume it and validate that querying MsQuic support no longer creates threads.
Describe the feature you'd like supported
In .NET Runtime, there is some logic conditioned on QUIC support on the platform (related to HTTP3). When checking QUIC support, we load the MsQuic library into the process and check the version (and query the TLS backend type), if compatible, we set some global flag.
However, calling MsQuicOpenVersion causes some threads to be created, which increases overall resources used by .NET programs even if they end up not using QUIC at all.
Proposed solution
Initialize the threadpool(s) lazily once the first Connection or Listener is created.
Additional context
We have resorted to a temporary workaround of calling MsQuicClose and later lazily reopening the library when necessary.
The text was updated successfully, but these errors were encountered: