Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change PipeStream's sync I/O cancellation support to avoid blocking CancellationTokenSource.Cancel #72612

Merged
merged 3 commits into from
Jul 22, 2022

Conversation

stephentoub
Copy link
Member

In a degenerate case, where cancellation is requested between the cancellation being registered and the I/O being performed, and where the thread performing the I/O is delayed significantly, the thread calling CTS.Cancel to cancel the operation could be blocked waiting for the callback cancellation loop which is in turn waiting for the I/O to be performed.

This changes the implementation to not block Cancel by instead queueing the cancellation handling.

It also factors the whole implementation of the async-over-sync support into a helper class, setting us up to reuse it elsewhere as needed (and cleaning up the PipeStream code to avoid duplication).

Addresses feedback at cdc5fa4#r79068435.

…ancellationTokenSource.Cancel

In a degenerate case, where cancellation is requested between the cancellation being registered and the I/O being performed, and where the thread performing the I/O is delayed significantly, the thread calling CTS.Cancel to cancel the operation could be blocked waiting for the callback cancellation loop which is in turn waiting for the I/O to be performed.

This changes the implementation to not block Cancel by instead queueing the cancellation handling.

It also factors the whole implementation of the async-over-sync support into a helper class, setting us up to reuse it elsewhere as needed (and cleaning up the PipeStream code to avoid duplication).
@ghost
Copy link

ghost commented Jul 21, 2022

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

In a degenerate case, where cancellation is requested between the cancellation being registered and the I/O being performed, and where the thread performing the I/O is delayed significantly, the thread calling CTS.Cancel to cancel the operation could be blocked waiting for the callback cancellation loop which is in turn waiting for the I/O to be performed.

This changes the implementation to not block Cancel by instead queueing the cancellation handling.

It also factors the whole implementation of the async-over-sync support into a helper class, setting us up to reuse it elsewhere as needed (and cleaning up the PipeStream code to avoid duplication).

Addresses feedback at cdc5fa4#r79068435.

Author: stephentoub
Assignees: -
Labels:

area-System.IO

Milestone: -

Copy link
Member

@adamsitnik adamsitnik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you for the explanation @stephentoub

@stephentoub stephentoub merged commit a68ab4a into dotnet:main Jul 22, 2022
@stephentoub stephentoub deleted the asyncioasync branch July 22, 2022 21:41
@ghost ghost locked as resolved and limited conversation to collaborators Aug 22, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants