-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use generated PInvokes and exchange types #50685
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving adding the new dependency, shouldn't be any problems there
@wtgodbe thoughts on why this failed source build? Should that apply here? |
Tagging @MichaelSimons for the new dependency question to make sure this is also not an issue for source-build. Michael, we don't think this should require a new prebuilt as this is only for windows, but I wanted to check with you anyway. |
97af338
to
09966ae
Compare
what's this doing under the covers -- is it a library, or a source generator? |
It's a source generator, it's creating the pinvoke definitions for us and embedding them in our dll.
It used to be a much bigger difference when I was pulling in all of the Http.Sys types, that's why I called it out. I've scoped it down to only the types we actually use and the difference is negligible. In fact, after my latest changes the dll is now smaller than the original. |
/cc @jkoritzinsky |
Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime. |
Is this an area of active development? If so, then this is true otherwise this sort of change doesn't tend to add a lot of value.
If you can share what you've tried the interop team can help root out the issue. |
Yes, we have partner teams request/contribute new features here regularly.
Any attempt I've made to call any generated APIs that take a NativeOverlapped do not work. I suspect part of the problem is that in most cases they take a NativeOverlapped and I am starting with a *NativeOverlapped or a SafeNativeOverlapped and there's some issue with the conversion. A live demo might be best, I'll ping you. For example, when I try HttpReceiveHttpRequest:
|
Seems to be an issue with the code generator: microsoft/CsWin32#1066 |
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
@adityamandaleeka thoughts on merging this? The NativeOverlapped issue isn't blocking and might take some time to resolve. |
Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime. |
/azp run |
Azure Pipelines successfully started running 3 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there details about where the native overlapped issue shows up and what our reaction will be when the issue is fixed?
src/Servers/HttpSys/src/Microsoft.AspNetCore.Server.HttpSys.csproj
Outdated
Show resolved
Hide resolved
@@ -117,14 +116,14 @@ private uint QueueBeginGetContext() | |||
_requestContext.RequestId, | |||
// Small perf impact by not using HTTP_RECEIVE_REQUEST_FLAG_COPY_BODY | |||
// if the request sends header+body in a single TCP packet | |||
(uint)HttpApiTypes.HTTP_FLAGS.NONE, | |||
0u, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels like a small loss in code quality. Is there not a "none" flag in the httpsys headers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, there isn't. There isn't one defined natively either.
https://learn.microsoft.com/en-us/windows/win32/api/http/nf-http-httpreceivehttprequest
Value | Meaning |
---|---|
0 (zero) | Only the request headers are retrieved; the entity body is not copied. |
HTTP_RECEIVE_REQUEST_FLAG_COPY_BODY | The available entity body is copied along with the request headers. The pEntityChunks member of the HTTP_REQUEST structure points to the entity body. |
HTTP_RECEIVE_REQUEST_FLAG_FLUSH_BODY | All of the entity bodies are copied along with the request headers. The pEntityChunks member of the HTTP_REQUEST structure points to the entity body. |
if (!started) | ||
{ | ||
statusCode = _requestContext.Response.SendHeaders(ref allocator, dataChunks, null, flags, false); | ||
} | ||
else | ||
{ | ||
fixed (HttpApiTypes.HTTP_DATA_CHUNK* pDataChunks = dataChunks) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is because dataChunks
comes from the unmanaged heap right? We just forgot to remove fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the fixed is now part of the generated code.
@@ -91,9 +92,10 @@ public enum REQUEST_NOTIFICATION_STATUS | |||
private static partial int http_get_application_properties(out IISConfigurationData iiConfigData); | |||
|
|||
[LibraryImport(AspNetCoreModuleDll)] | |||
[SuppressMessage("LibraryImportGenerator", "SYSLIB1051:Specified type is not supported by source-generated P/Invokes", Justification = "The enum is handled by the runtime.")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't appreciate that the generated type HTTP_REQUEST_PROPERTY is an enum, but it works fine.
@@ -43,5 +43,10 @@ public HttpClient CreateClient(HttpMessageHandler messageHandler) | |||
}; | |||
} | |||
|
|||
public void Dispose() | |||
{ | |||
HttpClient.Dispose(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weren't there issues with this when Hao tried it before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We finally got confirmation that this issue is a bug that's been fixed in a future version of IIS/Windows. I don't recall any issues with the mitigation?
I'll file a followup issue once this is merged. When the generator is fixed we should be able to remove additional pinvoke definitions from HttpApi such as HttpWaitForDisconnectEx, HttpReceiveRequestEntityBody, etc. Maybe all of them? |
nice to see 1500 lines of code vanish. |
Hi @danmoseley. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context. |
This reverts commit 7f18f8f. # Conflicts: # eng/Versions.props # src/Servers/HttpSys/src/AsyncAcceptContext.cs # src/Servers/HttpSys/src/AuthenticationManager.cs # src/Servers/HttpSys/src/Microsoft.AspNetCore.Server.HttpSys.csproj # src/Servers/HttpSys/src/NativeMethods.txt # src/Servers/IIS/IIS/src/Microsoft.AspNetCore.Server.IIS.csproj
https://github.com/microsoft/cswin32 is a tool used to generate PInvoke interop code for Windows APIs. Http.Sys has a lot of hand rolled interop code that can be replaced with generated code. This should help reduce maintenance, improve correctness, and develop new features.
Open questions:
Dll size: