Nick Banks

> @nibanks Is your target i686? We're just running on a `windows-2022` agent in Azure Pipelines. I assume it's x64. cc @thhous-msft

I have only glanced over the recent updates/discussion, but I recommend not having a notion of "default" stream and completely separating out the connection and stream objects. It's entirely possible...

> The fundamental premise of the option is to reuse as much existing API as possible. Pretty much ever QUIC API I know of is either a completely separate, new...

I'll take a look!

I _think_ the following would fix the `EncodeHeaders` issue: ``` --- a/lib/msh3.hpp +++ b/lib/msh3.hpp @@ -52,6 +52,7 @@ enum H3SettingsType { // Contiguous buffer for (non-null-terminated) header name and value...

For this one, I'm not sure why it claims there is uninitialized memory access. ``` ==1929954== Syscall param sendmsg(mmsg[0].msg_hdr.msg_iov[0]) points to uninitialised byte(s) ==1929954== at 0x4E40936: sendmmsg (sendmmsg.c:31) ==1929954== by...

It looks like we're missing a call to `MsH3RequestClose` for the `stream->req`. Not sure how I missed that originally. Sorry. You just need to call that when you're done with...

cc @csujedihy

I am coalescing the (possible) wait and the return of completions, but I'm not sure if it's very efficient to do the following with the existing APIs (I'd be happy...

So, should I update my function above to `return io_uring_peek_batch_cqe(queue, events, count);` instead of `return result == 0 ? 1 : 0;` Is that really optimal? Would/could it be more...