在Application.Idle中调用DoEvents

Question

我远离 Application.DoEvents，因为存在重入问题，而且总有另一种方法可以避免阻塞 UI。长期以来，我更喜欢在 Application.Idle 事件中执行后台工作，作为多线程的简单替代方案。但是，对于长时间运行的任务，使用 DoEvents 循环在 Application.Idle 中运行操作是否可以接受？

class LongRunningTask : IDisposable {

    public LongRunningTask(IEnumerable<Tidbit> listOfDataToBeProcessed) {
       Application.Idle += OnIdle;
    
        foreach(Tidbit t in listofDataToBeProcessed) {
            tidbits.Enqueue(t);
        }
    }
    
    // Small pieces of data to process
    Queue<Tidbit> tidbits = new Queue<Tidbit>();
    
    void OnIdle(object sender, EventArgs e) {
        while(tidbits.Count > 0) {
            var tidbit = tasks.Dequeue();
            tidbit.Process();
            // Process any messages that have queued up
            // while the data was being processed
            Application.DoEvents();
        }
    }
    
    public void Dispose() {
        Application.Idle -= OnIdle;
    }
}

这里的逻辑是，在我们调用 DoEvents 的 Application.Idle 事件中，没有排队的消息，因此我们不应该能够重新输入代码。每个花絮都会被足够快地处理，因此它不会显着占用消息队列（或 UI）。

那么，这种方法有什么坏处或缺点吗？即，在 Idle 事件中调用 DoEvents 是否安全？我确实知道 C# 5 将有一个功能来解决这种情况，但对于我们这些不使用 C# 5 的人来说（这是大多数我们现在），出于普遍的好奇心，这是一个好计划吗？或者是否有更简单的替代方案可以在长时间运行的操作期间处理消息而无需诉诸多线程？

请不要以为我想象这是一颗灵丹妙药。我知道它与任何异步方法都有相同的缺陷。我知道一个人必须仍然能够保持他的应用程序处于一致的状态。我知道知道有多线程解决方案。我正在避免那些。为什么？因为多线程比较复杂。我不认为这是不切实际的。

Answer 1

您在这里所做的事情看起来很像协作多任务处理。这是一个有趣的想法，但我想说你真的应该使用多线程来做这样的事情。 .NET 有很多帮助系统，例如 Task.Factory.StartNew() 和 TPL 库，它们确实让这一切变得简单。

我建议不要这样做。

但需要明确的是：我没有明确的理由反对它。与许多有关编程的领域一样：如果它有效，它就有效。但是，您将不应该混合在一起的东西混合在一起，特别是后台任务和 UI 任务。我相信，当您分离后台任务并开始着手使用多线程、线程池、后台任务和 TPL 时，您很快就会发现它确实有效，并且从长远来看会让生活变得更轻松。