[QUIC] Abort after Dispose is no-op #57318
Conversation
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsAllow calling Abort(Read|Write) after disposing. The only safe option to do so is to make them no-op in that case (see my comment in code). Fixes #56683
|
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsAllow calling Abort(Read|Write) after disposing. The only safe option to do so is to make them no-op in that case (see my comment in code). Fixes #56683
|
| { | ||
| // Dispose already triggered graceful shutdown | ||
| // It is unsafe to try to trigger abortive shutdown now, because final event arriving after Dispose releases SafeHandle | ||
| // so if it arrives after our check but before we call msquic, me might end up with access violation |
There was a problem hiding this comment.
Would it help if we send the abort only if the SendState was < Aborted? Few lines bellow we test the state, we could as well use similar pattern we do elsewhere with shouldAbort, set it to true only if we change the state and send the Abort only in such cases.
If this is something we could do, it might also help with the concern you raised in #57156, since it would provide the "locking" security via the SendState property.
There was a problem hiding this comment.
Discussed offline that the suggestion is good, but not directly related to the change, so it should be done in a separate PR
ghost
locked as resolved and limited conversation to collaborators
Allow calling Abort(Read|Write) after disposing. The only safe option to do so is to make them no-op in that case (see my comment in code).
Fixes #56683