Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the second patch in a patch set of three patches, the first being #82 (the first commit in this PR is #82).
When a client disconnects,
http2
kills the corresponding handlers. This may be fine for a webserver where the handler is just feeding the client information, but it's not fine in the general case. For example, I am building a gRPC library; when a client makes a remote procedure call, the server handler must have the option to terminate cleanly; after all, an RPC could be anything, and the server might need to execute some code after the client has told it all it needs to; maybe it needs to write to a database, maybe it needs to make RPC calls of its own, maybe a lot of things; simply killing the handler is not ok.In my library I am isolating the handler from the
KilledByHttp2ThreadPoolManager
exception by running it in a separate thread; when the parent thread receives theKilledByHttp2ThreadPoolManager
exception, it marks some local state to indicate that the handler is no longer able to send anything to the client. If the handler attempts to do so at this point, an exception will be raised, but otherwise the handler is allowed to continue.On the input side things are more complicated, however, which is where this PR comes in. While it is possible to have some local state indicating that the handler shouldn't expect any more input from the client either, there might still be unprocessed input from the client in the
TQueue
. We don't get that direct access to thatTQueue
in thehttp2
API; all we have isgetRequestBodyChunk
; this makes it difficult to write code that says "check this local piece of state but only if theTQueue
is exhausted".Prior to this PR, if we call
getRequestBodyChunk
when theTQueue
is empty, we get an exception, but not a useful one ("thread blocked indefinitely"). This PR changes this by making two changes:TQueue
can carry an exception; when we encounter this exception, it will be raised ingetRequestBodyChunk
.ConnectionIsClosed
) we write an empty bytestring to the queue, to allow handlers to detect normal client termination; if we terminate with any other exception, we write that exception to the queue, allowing the handler to detect that the client terminated with an exception.