Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

Port to RC2: Replace StreamAsyncHelper with StreamApmExtensions in System.Net.Security#7819

Merged
joshfree merged 1 commit into
dotnet:release/1.0.0-rc2from
stephentoub:port7800
Apr 18, 2016
Merged

Port to RC2: Replace StreamAsyncHelper with StreamApmExtensions in System.Net.Security#7819
joshfree merged 1 commit into
dotnet:release/1.0.0-rc2from
stephentoub:port7800

Conversation

@stephentoub
Copy link
Copy Markdown
Member

#7800

System.Net.Security was originally written to use Stream.Begin/EndRead/Write. When it was ported to .NET Core, it took a dependency on a helper that provided such Begin/End methods, but this helper was originally written for a different purpose: providing async Begin/End wrappers for the synchronous Read/Write methods. As a result of this mismatch, the async calls in System.Net.Security are queueing work items that then do work synchronously, blocking thread pool threads unnecessarily. This commit changes those helpers to sit on top of ReadAsync/WriteAsync instead. Eventually System.Net.Security should have its async I/O redone to sit natively on ReadAsync/WriteAsync using async/await, as it'll result in less overhead, but for now with minimal changes this improves the scalability of the library.

…rity

System.Net.Security was originally written to use Stream.Begin/EndRead/Write.  When it was ported to .NET Core, it took a dependency on a helper that provided such Begin/End methods, but this helper was originally written for a different purpose: providing async Begin/End wrappers for the synchronous Read/Write methods.  As a result of this mismatch, the async calls in System.Net.Security are queueing work items that then do work synchronously, blocking thread pool threads unnecessarily.  This commit changes those helpers to sit on top of ReadAsync/WriteAsync instead.  Eventually System.Net.Security should have its async I/O redone to sit natively on ReadAsync/WriteAsync using async/await, as it'll result in less overhead, but for now with minimal changes this improves the scalability of the library.
@joshfree joshfree added the blocking Marks issues that we want to fast track in order to unblock other important work label Apr 17, 2016
@joshfree joshfree added this to the 1.0.0-rc2 milestone Apr 17, 2016
@joshfree
Copy link
Copy Markdown
Member

LGTM

@joshfree
Copy link
Copy Markdown
Member

/cc @ellismg

@joshfree
Copy link
Copy Markdown
Member

All CI checks have passed. Proactively merging partner blocking bug into 1.0.0-rc2 rel tonight ahead of actual NET Core War review/approval so this can be part of Sunday night's release build. We'll hold off on updating the CLI or pushing out new builds to downstream teams until the review occurs on Monday in case there's a call not to take this for rc2.

@ellismg @eerhardt @Petermarcu @leecow

@joshfree joshfree merged commit 2f63fd1 into dotnet:release/1.0.0-rc2 Apr 18, 2016
@eerhardt
Copy link
Copy Markdown
Member

Let me know if it gets approved or not. The PR into CLI will automatically get created tonight. But we won't merge it until this build is approved for RC2.

@stephentoub stephentoub deleted the port7800 branch April 19, 2016 18:32
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-System.Net blocking Marks issues that we want to fast track in order to unblock other important work

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants