#monitor #runtimes #async #task #time #try #liveliness

async-liveliness-monitor

为您的异步运行时提供活力监控

2个版本

0.1.1 2022年11月17日
0.1.0 2022年10月3日

#869 in 并发

Download history 722/week @ 2024-04-03 806/week @ 2024-04-10 967/week @ 2024-04-17 723/week @ 2024-04-24 565/week @ 2024-05-01 690/week @ 2024-05-08 536/week @ 2024-05-15 541/week @ 2024-05-22 663/week @ 2024-05-29 575/week @ 2024-06-05 694/week @ 2024-06-12 728/week @ 2024-06-19 602/week @ 2024-06-26 742/week @ 2024-07-03 598/week @ 2024-07-10 486/week @ 2024-07-17

每月下载量 2,609

MIT 协议

11KB
140

为您的异步运行时提供活力监控

异步Rust允许我们在不分配完整线程的情况下调度大量任务。

这是通过在每个 .await 点将这些任务拆分为更小的任务来实现的,这标志着任务将控制权交还给执行器。

然而,通过在异步代码中混合同步代码,意外地挂起执行器线程是非常容易的。由于大多数执行器使用有限线程池,因此可能会发生特殊类型的死锁,即所有执行器线程都挂起,但触发它们解挂的事件是由等待执行的任务触发的。

这种“软”死锁,即向执行器添加线程可能会(但不一定)使应用程序恢复正常,通常被称为“执行器停滞”。

什么是活力监控器

这实际上是一个非常简单的事情:它是一个将在循环中运行的异步任务,在立即交还给执行器之前更新一个共享值以显示活力。

这个是如何工作的?

在这里,共享值是一个原子 i64,它被包装起来以允许将其作为原子的 std::time::Instant 处理。

任务持有对该共享值的弱引用,如果不再存在任何强引用,则将停止。在创建此任务时,将共享值的强引用返回给您,以供您按需处理。

我应该在我的异步库中包含这个吗?

也许吧:异步库的作者通常比普通人更了解这些类型的问题。向用户提供一种简单的方式来使用活力监控器可以让他们发现他们可能做错了什么。

然而,最终用户应该处理返回的监控器(通常是通过以低优先级启动监视器线程),因为只有他们才知道他们应用程序的完整行为以及它能否从执行器停滞中恢复。

我应该在我的可执行文件中包含这个吗?

当然。如果您的应用程序对性能的要求极高,您可能希望将其设置为可选,这主要是因为活力监控器必须位于一个与异步执行器独立的线程上。如果您可以腾出一个低优先级的线程和低开销的任务,您可能应该默认启用它,因为执行器停滞往往会变成海森堡虫,如果您的应用程序受到它们的困扰,您将需要任何可能的帮助。

无运行时依赖