Python-是时间。睡眠（n）cpu密集型？

Question

我一直在考虑在python脚本中使用time.sleep(n)使其以不同的间隔执行作业。伪代码看起来像：

total_jobs = [...]

next_jobs_to_run = next_closest(total_jobs)
min_time_to_wait = closestTime(nextJobsToRun)

wait until min_time_to_wait
run them all 
get next jobs

总而言之，程序会一直运行到下一个任务需要执行为止。它运行作业，找到要运行的下一个作业，并一直睡眠，直到需要运行下一个作业（继续无限）。我计划在linux机器上运行这个——使用cron作业是可能的。有人对这两者有意见吗？

Answer 1

不，它不是处理器密集型的。它让处理器空闲。

根据the documentation，它暂停执行，这意味着它不是处理器密集型的。一个busy wait将是处理器密集型的。

Answer 2

不，它不是CPU密集型的。

The documentation说：

Suspend execution for the given number of seconds.

Python实际上不能保证在每一个可能的实现中，这意味着操作系统永远不会在睡眠期间调度您的进程。但是在每一个平台上，Python都试图做一些适当的事情，在指定的时间内阻塞，而不使用任何CPU。在某些平台上，这可能仍然意味着一点CPU，但它将尽可能少。

特别是，既然你问过linux，大概还有CPython：

在linux和大多数其他POSIX平台上，它通常使用select。见the 3.3 source。

man page非常清楚地表明，select一直挂起，直到信号、超时或准备好I/O（在本例中，没有FD，因此后者是不可能的）。

您可以阅读内核源代码以获得完整的详细信息，但基本上，除非有任何意外的信号，否则根本不会安排您的日程，除了在select开始时可能有少量的旋转（作为对select几乎可以立即返回的情况的优化）。

---

在总结过程中，问题从“是sleepCPU密集型”变为“我应该使用sleep还是cron作业？”

不管怎样，你在等的时候不会烧掉任何CPU。有一些优点和缺点，但大多数都是微不足道的。从（大体上，主观上）最重要到最不重要的cron作业：

• 允许配置，例如，在不编辑源代码的情况下更改计划。
• 需要配置才能工作。
• 意味着更少的代码意味着更少的bug，也意味着未来的读者理解的更少。
• 将在系统关闭期间持续。
• 即使脚本以异常或信号退出，也将再次激发。
• 如果它的调度间隔错过N次（未指定，并且不同的cron实现执行不同的操作），则可能会触发0、1或N次，而不是保证0。
• 有更好的机会处理系统时钟的变化。
• 每次启动都要为进程启动、解释器启动等支付费用。
• 不会浪费页表和进程表空间，因为没有进程正在运行，也没有内存映射。