It's not generally clear why the changes in this file matter. Are they primarily about avoiding CreateHttpStreamContext(...) in the else portion of CreateHttp3Stream<TContext>(...)❔ (I'm somewhat unsure whether I'm missing another branch where CreateHttpStreamContext(...) is no longer called.)

Separately context and _context are both used below. Could we use slightly more distinct names❔

Null out _stream inside the lock, I assume DisposeCore is safe outside of the lock.

I moved it because DisposeAsync can't happen inside a lock.

The stream shouldn't be used anymore because _processingTask is awaited. The one place it could be used, and _stream is accessed in a lock, is Abort.

I've changed Abort so that it takes a local copy of _stream and then checks it for null.

So basically, we need to be able to call _stream.Abort() while _stream.DisposeAsync() is running? And anything else would be invalid since middleware has already completed.

The only problem is that Abort() could in theory still be in the middle of executing while we return the context to the pool because it doesn't do any synchronization. This could be bad if Abort() does something like setting _serverAborted after the QuicStreamContext has already been pushed and poped from the pool and "reset". I don't think Abort() can be thread safe without acquiring the _shutdownLock.

The other thing to make sure of is that we null _stream out before it enters the pool. DisposeAsync() is always awaited by Http3Stream before it calls Dispose() which may pool this QuicStreamContext, so we're good. Maybe putting it at the start of Dispose() before the if (!_connection.TryReturnStream(this)) would make this more obvious.

I've changed:

• DisposeAsync to call stream.DisposeAsync before the lock, and moved setting _stream to null inside the lock again. I think I like it more now, but I don't think this makes a huge difference as draining will already have happened by other code awaiting WaitForWritesClosedAsync. Because draining has already happened, stream.DisposeAsync should complete immediately.
• Abort now checks for null _stream and uses lock when determining whether it should run.

Can we produce a different log (or no log?) when _stream is null which would imply the stream had already stopped?

I've made Abort exit immediately if _stream is null. There is nothing for it to do: no stream to abort and pipes are completed in dispose.

So basically, we need to be able to call _stream.Abort() while _stream.DisposeAsync() is running? And anything else would be invalid since middleware has already completed.

The only problem is that Abort() could in theory still be in the middle of executing while we return the context to the pool because it doesn't do any synchronization. This could be bad if Abort() does something like setting _serverAborted after the QuicStreamContext has already been pushed and poped from the pool and "reset". I don't think Abort() can be thread safe without acquiring the _shutdownLock.

The other thing to make sure of is that we null _stream out before it enters the pool. DisposeAsync() is always awaited by Http3Stream before it calls Dispose() which may pool this QuicStreamContext, so we're good. Maybe putting it at the start of Dispose() before the if (!_connection.TryReturnStream(this)) would make this more obvious.