- Notifications
You must be signed in to change notification settings - Fork311
Merge | TdsParserStateObject PacketHandle usage#3353
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
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.
All of your changes look reasonable.
Would you be able to add a high level summary to the PacketHandle class docs that covers when the different packet types are used? In particular, it's not obvious to me when we would use NativePointerType vs NativePacketType.
Bigger picture (and not blocking for this PR, just looking to discuss), do you have any insight into what this design pattern gives us? It feels like we're fighting the type system. I can't think of a reason why we'd want this pattern vs just using the underlying types directly or a ref struct per underlying type, but I may be missing something.
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
Thanks. The PacketHandle and SessionHandle designs were added indotnet/corefx#34044, and they were added to avoid boxing. This boxing was introduced as part of the original implementation of the managed SNI indotnet/corefx#16589. The original native SNI design had the two types we care about (IntPtr and SNIPacket) and this has evolved from that. To speculate on the original design pattern: it feels like we're driven partially by marshalling here. When a PacketHandle's Strictly speaking, I'm not sure we'd need to maintain that separation; I'd personally be surprised if the unmanaged SNI DLL had a type separation between the inbound and the outbound packets, so the managed library might not need it either. If there's no separation, we might be able to rely on the normal SafeHandle marshalling mechanisms to let us use SNIPacket instances from end to end. This'd simplify matters, but it'd also increase GC traffic (because every packet received from SQL Server is now a full object with its own finalizer, rather than just an IntPtr.) If we wanted to avoid that specific regression, another way of representing this might be a generics-based design similar to below: internalabstractclassTdsParserStateObject<TOutputPacket,TInputPacket,TSession>{publicabstractTSessionSession{get;}publicabstractSetPacketData(TOutputPacketpacket,byte[]buffer,intbytesUsed);publicabstractvoidReleasePacket(TInputPacketsyncReadPacket);// This was in TdsParser, but would need to be be moved into TdsParserStateObject - it's the// only place outside this class (besides NativeSspiContextProvider) where PacketHandle and SessionHandle are usedpublicvoidPostReadAsyncForMars();// ...}internalsealedclassTdsParserStateObjectNative:TdsParserStateObject<SNIPacket,IntPtr,SNIHandle>{}internalsealedclassTdsParserStateObjectManaged:TdsParserStateObject<SNI.SNIPacket,SNI.SNIPacket,SNI.SNIHandle>{} It might be worth considering and benchmarking after these are merged. |
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.
Would like to think through the PacketHandle class before we approve this. But otherwise, I think these will be good changes to move us through the merge classes.
Also, this is going to run into conflicts with#3345...
src/Microsoft.Data.SqlClient/src/Microsoft/Data/SqlClient/PacketHandle.Windows.csShow resolvedHide resolved
Uh oh!
There was an error while loading.Please reload this page.
src/Microsoft.Data.SqlClient/netfx/src/Microsoft/Data/SqlClient/TdsParserStateObject.netfx.csShow resolvedHide resolved
Uh oh!
There was an error while loading.Please reload this page.
src/Microsoft.Data.SqlClient/netfx/src/Microsoft/Data/SqlClient/TdsParserStateObject.netfx.csShow resolvedHide resolved
Uh oh!
There was an error while loading.Please reload this page.
src/Microsoft.Data.SqlClient/netfx/src/Microsoft/Data/SqlClient/TdsParserStateObject.netfx.csShow resolvedHide resolved
Uh oh!
There was an error while loading.Please reload this page.
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
codecovbot commentedMay 21, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@## main #3353 +/- ##==========================================- Coverage 65.16% 61.38% -3.78%========================================== Files 300 294 -6 Lines 65379 65082 -297 ==========================================- Hits 42606 39953 -2653- Misses 22773 25129 +2356
Flags with carried forward coverage won't be shown.Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
0c5155d
intodotnet:mainUh oh!
There was an error while loading.Please reload this page.
* Port PacketHandle to netfx* Remove PacketHandle alias shim* Align netfx use of PacketHandle* Merge IsPacketEmpty* Merge ReleasePacket* Merge ReadAsync, ReadSyncOverAsyncAlso move ReadSyncOverAsync down in netcore's TdsParserStateObjectNative to aid later merge* Merge IsFailedHandle* Merge SniPacketGetData* Merge EmptyReadPacketAlso reorder member in TdsParserStateObjectNative to simplify later merge* Merge CheckPacket* Merge WritePacket, IsValidPacket* Merge GetResetWritePacket* Merge ClearAllWritePackets, AddPacketToPendingList, RemovePacketFromPendingList* Improve diff between versions of TdsParserStateObjectNative* PR feedback from#3353 - format IsValidPacket* Address merge conflicts* Merge DisposePacketCacheThis also allows _writePacketCache to be migrated to TdsParserStateObjectNative in netfx.
Relates to#1261.
This continues the
TdsParserStateObject
merge work. At present, there's a deviation between netcore and netfx: netcore uses aPacketHandle
type to shuttle the native or managed packet handles around, while netfx just treats PacketHandle as an alias forIntPtr
. This PR is focused strictly on merging that handling, so we can move on to the identical methods which use the type.