External Execution Interface #4616
Conversation
nibanks
added
Area: Performance
Area: API
Area: Core
nibanks
changed the title
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4616 +/- ##
==========================================
- Coverage 87.20% 86.60% -0.60%
==========================================
Files 56 56
Lines 17363 17378 +15
==========================================
- Hits 15141 15051 -90
- Misses 2222 2327 +105 ☔ View full report in Codecov by Sentry. |
| QUIC_STATUS Status = MsQuic->ExecutionCreate(QUIC_EXECUTION_CONFIG_FLAG_NONE, 0, 1, &ExecConfig, &ExecContext); | ||
| ``` | ||
|
|
||
| The above code createa a new IOCP (for Windows), sets up an execution config, indicating an ideal processor of 0 and the pointer to the IOCP, and then calls MsQuic to create 1 execution context. |
There was a problem hiding this comment.
A processor of 0 has no clear, unambiguous meaning on Win32. A PROCESSOR_NUMBER is the only unambiguous processor identifier in Windows user mode, unless MsQuic provides its own canonical representation to apps.
There was a problem hiding this comment.
One could argue that 0 should always map to Group 0, Number 0 in any sensible CPU numbering scheme, but certainly once you reach the integer 1, the point stands. The NT processor index 1 could be Group 1, Number 0, even if Group 0, Number 1 exists, and vice versa.
There was a problem hiding this comment.
We can look around to see how other platform abstraction layers (std, boost) solve this problem.
There was a problem hiding this comment.
According to stackoverflow, boost sidesteps the problem by allowing you to get a native thread handle, and then go off and call platform-specific affinity routines yourself. Personally I think an int should be a reasonable way to identify CPUs, so if QUIC just exposes ConvertProcessorNumberToProcessorIndex and ConvertProcessorIndexToProcessorNumber helper routines on Windows, you'd be set.
There was a problem hiding this comment.
Alternatively, you could typedef int QUIC_CPU_ID everywhere else and typedef PROCESSOR_NUMBER QUIC_CPU_ID on Windows and let apps deal with the difference if they also compile cross-plat.
|
|
||
| To create an execution context, the app much first create an event queue object, which is a platform specific type: | ||
|
|
||
| - Windows: IOCP |
There was a problem hiding this comment.
why do we expose a platform specific queue object rather than having a more abstracted interface?
There was a problem hiding this comment.
Such as what? The reason we use the platform queue object is because that is also a requirement for other (i.e. storage) IO. So, it's not expected to be a new requirement. Also, this is all opt-in. They can continue to use MsQuic without doing this, and it will simply create the background threads still.
There was a problem hiding this comment.
I meant a generic platform-independent interface for queue objects.
So, for the apps to opt in, they still have to create a new IOCP handle exclusively for msquic, right? i.e. they can't just share whatever IOCP handles they use for file IO for msquic unless they change all their IO logic to use the new sqe/cqe pattern.
There was a problem hiding this comment.
No, they shouldn't create anything specific for MsQuic. If they have an epoll queue (on Linux) for their storage IO, they should reuse that for MsQuic.
Description
Closes #1923.
Provides an interface for the application layer to completely control execution of all MsQuic work. In other words, MsQuic would create no threads internally.
Testing
TODO
Documentation
TODO