Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync by stephentoub · Pull Request #99632 · dotnet/runtime

stephentoub · 2024-03-12T18:27:06Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Fixes#99564

dotnet-policy-service · 2024-03-12T18:27:36Z

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

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-05-17T03:32:25Z

/backport to release/8.0-staging

github-actions · 2024-05-17T03:32:36Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/9122547886

github-actions · 2024-05-17T03:34:10Z

@stephentoub backporting to release/8.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Using index info to reconstruct a base tree...
M	src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
CONFLICT (content): Merge conflict in src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-05-17T03:34:11Z

@stephentoub an error occurred while backporting to release/8.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

…AvailableAsync (#102376) * Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync (#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method. * Enable DataFlow package in servicing --------- Co-authored-by: Eric StJohn <ericstj@microsoft.com>

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-03-12T18:27:06Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Fixes#99564

dotnet-policy-service · 2024-03-12T18:27:36Z

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

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-05-17T03:32:25Z

/backport to release/8.0-staging

github-actions · 2024-05-17T03:32:36Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/9122547886

github-actions · 2024-05-17T03:34:10Z

@stephentoub backporting to release/8.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Using index info to reconstruct a base tree...
M	src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
CONFLICT (content): Merge conflict in src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-05-17T03:34:11Z

@stephentoub an error occurred while backporting to release/8.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

…AvailableAsync (#102376) * Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync (#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method. * Enable DataFlow package in servicing --------- Co-authored-by: Eric StJohn <ericstj@microsoft.com>

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-03-12T18:27:06Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Fixes#99564

dotnet-policy-service · 2024-03-12T18:27:36Z

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

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-05-17T03:32:25Z

/backport to release/8.0-staging

github-actions · 2024-05-17T03:32:36Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/9122547886

github-actions · 2024-05-17T03:34:10Z

@stephentoub backporting to release/8.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Using index info to reconstruct a base tree...
M	src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
CONFLICT (content): Merge conflict in src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-05-17T03:34:11Z

@stephentoub an error occurred while backporting to release/8.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

…AvailableAsync (#102376) * Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync (#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method. * Enable DataFlow package in servicing --------- Co-authored-by: Eric StJohn <ericstj@microsoft.com>

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-03-12T18:27:06Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Fixes#99564

dotnet-policy-service · 2024-03-12T18:27:36Z

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

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-05-17T03:32:25Z

/backport to release/8.0-staging

github-actions · 2024-05-17T03:32:36Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/9122547886

github-actions · 2024-05-17T03:34:10Z

@stephentoub backporting to release/8.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Using index info to reconstruct a base tree...
M	src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
CONFLICT (content): Merge conflict in src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-05-17T03:34:11Z

@stephentoub an error occurred while backporting to release/8.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

…AvailableAsync (#102376) * Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync (#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method. * Enable DataFlow package in servicing --------- Co-authored-by: Eric StJohn <ericstj@microsoft.com>

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-03-12T18:27:06Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Fixes#99564

dotnet-policy-service · 2024-03-12T18:27:36Z

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

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-05-17T03:32:25Z

/backport to release/8.0-staging

github-actions · 2024-05-17T03:32:36Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/9122547886

github-actions · 2024-05-17T03:34:10Z

@stephentoub backporting to release/8.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Using index info to reconstruct a base tree...
M	src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
CONFLICT (content): Merge conflict in src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-05-17T03:34:11Z

@stephentoub an error occurred while backporting to release/8.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

…AvailableAsync (#102376) * Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync (#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method. * Enable DataFlow package in servicing --------- Co-authored-by: Eric StJohn <ericstj@microsoft.com>

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-03-12T18:27:06Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Fixes#99564

dotnet-policy-service · 2024-03-12T18:27:36Z

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

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-05-17T03:32:25Z

/backport to release/8.0-staging

github-actions · 2024-05-17T03:32:36Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/9122547886

github-actions · 2024-05-17T03:34:10Z

@stephentoub backporting to release/8.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Using index info to reconstruct a base tree...
M	src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
CONFLICT (content): Merge conflict in src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-05-17T03:34:11Z

@stephentoub an error occurred while backporting to release/8.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

…AvailableAsync (#102376) * Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync (#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method. * Enable DataFlow package in servicing --------- Co-authored-by: Eric StJohn <ericstj@microsoft.com>

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-03-12T18:27:06Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Fixes#99564

dotnet-policy-service · 2024-03-12T18:27:36Z

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

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-05-17T03:32:25Z

/backport to release/8.0-staging

github-actions · 2024-05-17T03:32:36Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/9122547886

github-actions · 2024-05-17T03:34:10Z

@stephentoub backporting to release/8.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Using index info to reconstruct a base tree...
M	src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
CONFLICT (content): Merge conflict in src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-05-17T03:34:11Z

@stephentoub an error occurred while backporting to release/8.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

…AvailableAsync (#102376) * Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync (#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method. * Enable DataFlow package in servicing --------- Co-authored-by: Eric StJohn <ericstj@microsoft.com>

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-03-12T18:27:06Z

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak.

The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

Fixes#99564

dotnet-policy-service · 2024-03-12T18:27:36Z

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

OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub · 2024-05-17T03:32:25Z

/backport to release/8.0-staging

github-actions · 2024-05-17T03:32:36Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/9122547886

github-actions · 2024-05-17T03:34:10Z

@stephentoub backporting to release/8.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Using index info to reconstruct a base tree...
M	src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
CONFLICT (content): Merge conflict in src/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-05-17T03:34:11Z

@stephentoub an error occurred while backporting to release/8.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

…AvailableAsync (#102376) * Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync (#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method. * Enable DataFlow package in servicing --------- Co-authored-by: Eric StJohn <ericstj@microsoft.com>

…dotnet#99632) OutputAvailableAsync is not unregistering from the supplied CancellationToken. If a cancelable token is supplied and is long lived, each call with that token to OutputAvailableAsync will add another callback into that token, and that will continue to grow until either the token is dropped or has been cancellation requested. For a long-lived cancellation token, this is akin to a leak. The implementation was trying to be too clever in avoiding an additional continuation that was previously there. However, this continuation makes it a lot easier to avoid possible deadlocks that can occur if a cancellation request comes in concurrently with a message being pushed. Instead of trying to avoid it, just use an async method, which still incurs the extra task but does so with less allocation and greatly simplifies the code while also fixing the issue, as all cleanup can now be done in the continuation as part of the async method.

stephentoub added the area-System.Threading.Tasks label Mar 12, 2024

stephentoub added this to the 9.0.0 milestone Mar 12, 2024

dotnet-policy-serviceBot assigned stephentoub Mar 12, 2024

build-analysisBot mentioned this pull request Mar 12, 2024
mono_os_mutex_destroy: pthread_mutex_destroy failed with "Device or resource busy" #99609
Closed

stephentoub added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 13, 2024

stephentoub force-pushed the dataflowfix branch from e5274d3 to 19ed3ceCompare March 15, 2024 18:48

stephentoub force-pushed the dataflowfix branch from 19ed3ce to 847d8c4Compare May 6, 2024 17:16

stephentoub force-pushed the dataflowfix branch from 847d8c4 to 7780ca9Compare May 7, 2024 01:21

stephentoub removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label May 7, 2024

stephentoub requested a review from a teamMay 7, 2024 01:22

MihaZupan approved these changes May 16, 2024
View reviewed changes

Comment threadsrc/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs

stephentoub merged commit 84885d7 into dotnet:mainMay 17, 2024

stephentoub deleted the dataflowfix branch May 17, 2024 03:32

stephentoub mentioned this pull request May 17, 2024
[release/8.0] Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync #102376
Merged

github-actionsBot locked and limited conversation to collaborators Jun 16, 2024

stephentoub added the area-System.Threading.Tasks label Mar 12, 2024

stephentoub added this to the 9.0.0 milestone Mar 12, 2024

dotnet-policy-serviceBot assigned stephentoub Mar 12, 2024

build-analysisBot mentioned this pull request Mar 12, 2024
mono_os_mutex_destroy: pthread_mutex_destroy failed with "Device or resource busy" #99609
Closed

stephentoub added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 13, 2024

stephentoub force-pushed the dataflowfix branch from e5274d3 to 19ed3ceCompare March 15, 2024 18:48

stephentoub force-pushed the dataflowfix branch from 19ed3ce to 847d8c4Compare May 6, 2024 17:16

stephentoub force-pushed the dataflowfix branch from 847d8c4 to 7780ca9Compare May 7, 2024 01:21

stephentoub removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label May 7, 2024

stephentoub requested a review from a teamMay 7, 2024 01:22

MihaZupan approved these changes May 16, 2024
View reviewed changes

Comment threadsrc/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs

stephentoub merged commit 84885d7 into dotnet:mainMay 17, 2024

stephentoub deleted the dataflowfix branch May 17, 2024 03:32

stephentoub mentioned this pull request May 17, 2024
[release/8.0] Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync #102376
Merged

github-actionsBot locked and limited conversation to collaborators Jun 16, 2024

stephentoub added the area-System.Threading.Tasks label Mar 12, 2024

stephentoub added this to the 9.0.0 milestone Mar 12, 2024

dotnet-policy-serviceBot assigned stephentoub Mar 12, 2024

build-analysisBot mentioned this pull request Mar 12, 2024
mono_os_mutex_destroy: pthread_mutex_destroy failed with "Device or resource busy" #99609
Closed

stephentoub added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 13, 2024

stephentoub force-pushed the dataflowfix branch from e5274d3 to 19ed3ceCompare March 15, 2024 18:48

stephentoub force-pushed the dataflowfix branch from 19ed3ce to 847d8c4Compare May 6, 2024 17:16

stephentoub force-pushed the dataflowfix branch from 847d8c4 to 7780ca9Compare May 7, 2024 01:21

stephentoub removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label May 7, 2024

stephentoub requested a review from a teamMay 7, 2024 01:22

MihaZupan approved these changes May 16, 2024
View reviewed changes

Comment threadsrc/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs

stephentoub merged commit 84885d7 into dotnet:mainMay 17, 2024

stephentoub deleted the dataflowfix branch May 17, 2024 03:32

stephentoub mentioned this pull request May 17, 2024
[release/8.0] Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync #102376
Merged

github-actionsBot locked and limited conversation to collaborators Jun 16, 2024

stephentoub added the area-System.Threading.Tasks label Mar 12, 2024

stephentoub added this to the 9.0.0 milestone Mar 12, 2024

dotnet-policy-serviceBot assigned stephentoub Mar 12, 2024

build-analysisBot mentioned this pull request Mar 12, 2024
mono_os_mutex_destroy: pthread_mutex_destroy failed with "Device or resource busy" #99609
Closed

stephentoub added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 13, 2024

stephentoub force-pushed the dataflowfix branch from e5274d3 to 19ed3ceCompare March 15, 2024 18:48

stephentoub force-pushed the dataflowfix branch from 19ed3ce to 847d8c4Compare May 6, 2024 17:16

stephentoub force-pushed the dataflowfix branch from 847d8c4 to 7780ca9Compare May 7, 2024 01:21

stephentoub removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label May 7, 2024

stephentoub requested a review from a teamMay 7, 2024 01:22

MihaZupan approved these changes May 16, 2024
View reviewed changes

Comment threadsrc/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs

stephentoub merged commit 84885d7 into dotnet:mainMay 17, 2024

stephentoub deleted the dataflowfix branch May 17, 2024 03:32

stephentoub mentioned this pull request May 17, 2024
[release/8.0] Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync #102376
Merged

github-actionsBot locked and limited conversation to collaborators Jun 16, 2024

stephentoub added the area-System.Threading.Tasks label Mar 12, 2024

stephentoub added this to the 9.0.0 milestone Mar 12, 2024

dotnet-policy-serviceBot assigned stephentoub Mar 12, 2024

build-analysisBot mentioned this pull request Mar 12, 2024
mono_os_mutex_destroy: pthread_mutex_destroy failed with "Device or resource busy" #99609
Closed

stephentoub added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 13, 2024

stephentoub force-pushed the dataflowfix branch from e5274d3 to 19ed3ceCompare March 15, 2024 18:48

stephentoub force-pushed the dataflowfix branch from 19ed3ce to 847d8c4Compare May 6, 2024 17:16

stephentoub force-pushed the dataflowfix branch from 847d8c4 to 7780ca9Compare May 7, 2024 01:21

stephentoub removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label May 7, 2024

stephentoub requested a review from a teamMay 7, 2024 01:22

MihaZupan approved these changes May 16, 2024
View reviewed changes

Comment threadsrc/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs

stephentoub merged commit 84885d7 into dotnet:mainMay 17, 2024

stephentoub deleted the dataflowfix branch May 17, 2024 03:32

stephentoub mentioned this pull request May 17, 2024
[release/8.0] Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync #102376
Merged

github-actionsBot locked and limited conversation to collaborators Jun 16, 2024

stephentoub added the area-System.Threading.Tasks label Mar 12, 2024

stephentoub added this to the 9.0.0 milestone Mar 12, 2024

dotnet-policy-serviceBot assigned stephentoub Mar 12, 2024

build-analysisBot mentioned this pull request Mar 12, 2024
mono_os_mutex_destroy: pthread_mutex_destroy failed with "Device or resource busy" #99609
Closed

stephentoub added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 13, 2024

stephentoub force-pushed the dataflowfix branch from e5274d3 to 19ed3ceCompare March 15, 2024 18:48

stephentoub force-pushed the dataflowfix branch from 19ed3ce to 847d8c4Compare May 6, 2024 17:16

stephentoub force-pushed the dataflowfix branch from 847d8c4 to 7780ca9Compare May 7, 2024 01:21

stephentoub removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label May 7, 2024

stephentoub requested a review from a teamMay 7, 2024 01:22

MihaZupan approved these changes May 16, 2024
View reviewed changes

Comment threadsrc/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs

stephentoub merged commit 84885d7 into dotnet:mainMay 17, 2024

stephentoub deleted the dataflowfix branch May 17, 2024 03:32

stephentoub mentioned this pull request May 17, 2024
[release/8.0] Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync #102376
Merged

github-actionsBot locked and limited conversation to collaborators Jun 16, 2024

stephentoub added the area-System.Threading.Tasks label Mar 12, 2024

stephentoub added this to the 9.0.0 milestone Mar 12, 2024

dotnet-policy-serviceBot assigned stephentoub Mar 12, 2024

build-analysisBot mentioned this pull request Mar 12, 2024
mono_os_mutex_destroy: pthread_mutex_destroy failed with "Device or resource busy" #99609
Closed

stephentoub added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 13, 2024

stephentoub force-pushed the dataflowfix branch from e5274d3 to 19ed3ceCompare March 15, 2024 18:48

stephentoub force-pushed the dataflowfix branch from 19ed3ce to 847d8c4Compare May 6, 2024 17:16

stephentoub force-pushed the dataflowfix branch from 847d8c4 to 7780ca9Compare May 7, 2024 01:21

stephentoub removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label May 7, 2024

stephentoub requested a review from a teamMay 7, 2024 01:22

MihaZupan approved these changes May 16, 2024
View reviewed changes

Comment threadsrc/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs

stephentoub merged commit 84885d7 into dotnet:mainMay 17, 2024

stephentoub deleted the dataflowfix branch May 17, 2024 03:32

stephentoub mentioned this pull request May 17, 2024
[release/8.0] Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync #102376
Merged

github-actionsBot locked and limited conversation to collaborators Jun 16, 2024

stephentoub added the area-System.Threading.Tasks label Mar 12, 2024

stephentoub added this to the 9.0.0 milestone Mar 12, 2024

dotnet-policy-serviceBot assigned stephentoub Mar 12, 2024

build-analysisBot mentioned this pull request Mar 12, 2024
mono_os_mutex_destroy: pthread_mutex_destroy failed with "Device or resource busy" #99609
Closed

stephentoub added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Mar 13, 2024

stephentoub force-pushed the dataflowfix branch from e5274d3 to 19ed3ceCompare March 15, 2024 18:48

stephentoub force-pushed the dataflowfix branch from 19ed3ce to 847d8c4Compare May 6, 2024 17:16

stephentoub force-pushed the dataflowfix branch from 847d8c4 to 7780ca9Compare May 7, 2024 01:21

stephentoub removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label May 7, 2024

stephentoub requested a review from a teamMay 7, 2024 01:22

MihaZupan approved these changes May 16, 2024
View reviewed changes

Comment threadsrc/libraries/System.Threading.Tasks.Dataflow/src/Base/DataflowBlock.cs

stephentoub merged commit 84885d7 into dotnet:mainMay 17, 2024

stephentoub deleted the dataflowfix branch May 17, 2024 03:32

stephentoub mentioned this pull request May 17, 2024
[release/8.0] Fix cancellation unregistration in DataflowBlock.OutputAvailableAsync #102376
Merged

github-actionsBot locked and limited conversation to collaborators Jun 16, 2024

Uh oh!

Conversation

stephentoub commented Mar 12, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented Mar 12, 2024

Uh oh!

Uh oh!

stephentoub commented May 17, 2024

Uh oh!

github-actionsBot commented May 17, 2024

Uh oh!

github-actionsBot commented May 17, 2024

Uh oh!

github-actionsBot commented May 17, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

stephentoub commented Mar 12, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented Mar 12, 2024

Uh oh!

Uh oh!

stephentoub commented May 17, 2024

Uh oh!

github-actionsBot commented May 17, 2024

Uh oh!

github-actionsBot commented May 17, 2024

Uh oh!

github-actionsBot commented May 17, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

stephentoub commented Mar 12, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented Mar 12, 2024

Uh oh!

Uh oh!

stephentoub commented May 17, 2024

Uh oh!

github-actionsBot commented May 17, 2024

Uh oh!

github-actionsBot commented May 17, 2024

Uh oh!

github-actionsBot commented May 17, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

stephentoub commented Mar 12, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented Mar 12, 2024

Uh oh!

Uh oh!

stephentoub commented Mar 12, 2024•
edited
Loading

stephentoub commented Mar 12, 2024•
edited
Loading

stephentoub commented Mar 12, 2024•
edited
Loading

stephentoub commented Mar 12, 2024•
edited
Loading

stephentoub commented Mar 12, 2024•
edited
Loading