问题标签 [cancellation]

我有一种情况，我想允许用户在每次击键时输入 WPF 文本框，我调用 OnPropertyChanged 并推送到我的绑定源（使用 SourceUpdatedTrigger=PropertyChanged）我希望在尝试处理数据之前有一个短暂的延迟（比如说... 1 秒）可以把它想象成一个拼写检查系统，它在告诉用户他们不能拼写之前等待用户停止输入。

我的问题是：

在您实际取消之前工作正常，但是取消令牌源永久处于“已请求取消”状态，我必须重新实例化 CTS ......这似乎......从根本上是错误的......有没有更好的方法来“重置” CTS，但仍通知现有令牌他们应该取消？

我们的应用程序使用 TPL 序列化（可能）长时间运行的工作单元。工作（任务）的创建是用户驱动的，可以随时取消。为了有一个响应式的用户界面，如果当前的工作不再需要，我们想放弃我们正在做的事情，并立即开始一个不同的任务。

任务排队是这样的：

该DoWork方法包含一个长时间运行的调用，因此它并不像在token.IsCancellationRequested检测到取消时不断检查状态和放弃那样简单。即使任务被取消，长时间运行的工作也会阻止任务继续直到它完成。

我想出了两个示例方法来解决这个问题，但我不相信任何一个都是正确的。我创建了简单的控制台应用程序来演示它们是如何工作的。

需要注意的重要一点是在原始任务完成之前继续触发。

尝试#1：内部任务

这行得通，但“innerT”任务对我来说感觉非常笨拙。它还有一个缺点，就是迫使我重构以这种方式排队工作的代码的所有部分，因为必须将所有长时间运行的调用包装在一个新任务中。

尝试 #2：TaskCompletionSource 修补

这再次有效，但现在我有两个问题：

a) 感觉就像我在滥用 TaskCompletionSource，从不使用它的结果，并且在我完成工作时设置为 null。

b) 为了正确连接延续，我需要处理前一个工作单元的唯一 TaskCompletionSource，而不是为其创建的任务。这在技术上是可行的，但又让人觉得笨重和奇怪。

然后去哪儿？

重申一下，我的问题是：这些方法中的任何一种都是解决这个问题的“正确”方法，还是有更正确/优雅的解决方案可以让我过早中止长期运行的任务并立即开始继续？我更喜欢低影响的解决方案，但如果这是正确的做法，我愿意进行一些大规模的重构。

或者，TPL 是否是该工作的正确工具，或者我是否缺少更好的任务排队机制。我的目标框架是 .NET 4.0。

我在 SQL Server 中有一个存储过程，看起来像这样：

它从应用程序中调用，需要几秒钟才能运行。如果用户在它运行时取消它，我最终会在 Record 表中得到一个 StartTimestamp，但没有错误，也没有 EndTimestamp。我总是想知道用户启动了这个存储过程，但我也想总是记录它何时完成，无论是成功、错误还是被取消。

在 SQL Server 中有没有办法做到这一点？

谢谢

如果有人从星巴克登录电脑（例如），他们不小心选中了“记住我”选项，从而在该电脑上设置了一个持久性 cookie，有没有办法在不改变 cookie 名称的情况下从服务器拒绝该 cookie在 web.config 中？

我创建了一个类，其目的是抽象出对队列的并发访问控制。

该类被设计为在单个线程上实例化，由多个线程写入，然后从后续的单个线程中读取。

我在类中生成了一个长时间运行的任务，如果项目成功出列，它将执行阻塞循环并触发事件。

我的问题是：我是否执行取消长时间运行的任务并随后清理/重置CancellationTokenSource对象的正确使用？

理想情况下，我希望一个活动对象能够被停止和重新启动，同时保持可用性以添加到队列中。

我以 Peter Bromberg 的文章为基础：Producer/Consumer Queue and BlockingCollection in C# 4.0

下面的代码：

更新 这就是我最后所做的。它并不完美，但到目前为止正在完成这项工作。

输出是：

根据http://msdn.microsoft.com/en-us/library/dd321703.aspx我希望得到 AggregateException，看起来 throwOnFirstException 参数在这里没有任何意义。我的代码有什么问题。

我正在寻找一种方法，从信号处理程序中，有条件地中断系统调用，这种方式在处理信号时发生。具体来说，假设一个调用read正在处理中，并且SIGRT0被接收到。使用此信号处理程序SA_RESTART是因为它不想无条件地中断系统调用，但根据条件，我希望在信号处理程序read返回后EINTR立即返回。

我可以做到这一点的一种方法是为 设置另一个信号处理程序SIGRT1，为 的处理程序放入SIGRT1信号掩码，然后从处理程序SIGRT0中省略。然后处理程序can ，当第一个非中断信号处理程序返回时，第二个将触发并被中断。SA_RESTARTSIGRT1SIGRT0raise SIGRT1read

此解决方案的问题是其他进程可能会发送SIGRT1，从而导致意外EINTR发生。

有什么办法可以达到我想要的结果吗？

我的问题与其他询问故障地址的问题有些不同。我正在尝试实现一个可怕的黑客攻击，以确定信号是否中断了系统调用或普通用户代码，方法是检查保存的指令指针处的代码并将其与主机架构可能的系统调用入口指令进行比较继续运行。这是实现正确的 POSIX 线程取消的一部分，它不受我的旧问题中描述的竞争条件和资源泄漏的影响：

POSIX 取消点应该如何表现？

如果这种方法不可靠或有其他错误，我也想听听原因。

假设应用程序在取消点被阻塞，例如read，接收到信号并调用信号处理程序。Glibc/NPTL 通过在系统调用期间启用异步取消来实现取消点，据我所知，异步取消将在信号处理程序的整个持续时间内保持有效。这当然是非常错误的，因为有很多函数不是异步取消安全的，但需要安全地从信号处理程序调用。

这给我留下了两个问题：

• 我错了还是 glibc/NPTL 行为真的有这么危险的破坏？如果是这样，这种危险行为是否符合要求？
• 根据 POSIX，如果在进程执行作为取消点的函数时调用信号处理程序会发生什么？

编辑：我几乎说服自己，任何作为潜在目标的线程都pthread_cancel必须确保在该线程的上下文中永远不能从信号处理程序调用作为取消点的函数：

一方面，可以在可能被取消的线程中调用的任何信号处理程序以及使用任何 async-cancel-unsafe 函数的任何信号处理程序都必须在调用作为取消点的任何函数之前禁用取消。这是因为，从被信号中断的代码的角度来看，任何这样的取消都将等同于异步取消。另一方面，信号处理程序不能禁用取消，除非在调用信号处理程序时将运行的代码仅使用异步信号安全函数，因为pthread_setcancelstate它不是异步信号安全的。

目前有一个简单的工作流公开为服务端点。该服务与工作流实例 ID 相关，并且一切都按预期工作（2 个服务调用可用 ReceiveBegin、Execute）。

我的问题是我希望用户能够通过在工作流上调用另一个 Receive 来取消工作流的长时间运行部分。看过了，WorkflowApplication.Cancel但是当我将它作为 WCF 服务运行时，它似乎不可用。

该领域的文档似乎有点少，大多数 HOL 和示例都集中在托管工作流的控制台应用程序上。