multithreading - 纯 Haskell 代码是否需要线程池？

Question

在 Real World Haskell, Chapter 28, Software transactional memory ，开发了一个并发的网络链接检查器。它获取网页中的所有链接，并使用 HEAD 请求命中每一个链接，以确定链接是否处于事件状态。采用并发的方法来构建这个程序，并做出以下声明:

We can't simply create one thread per URL, because that may overburden either our CPU or our network connection if (as we expect) most of the links are live and responsive. Instead, we use a fixed number of worker threads, which fetch URLs to download from a queue.

我不完全理解为什么需要这个线程池而不是使用 forkIO对于每个链接。 AFAIK，Haskell 运行时维护一个线程池并适本地安排它们，所以我没有看到 CPU 过载。此外，在 a discussion about concurrency on the Haskell mailing list ，我发现以下语句朝着相同的方向发展:

The one paradigm that makes no sense in Haskell is worker threads (since the RTS does that for us); instead of fetching a worker, just forkIO instead.

线程池是否只需要网络部分，还是有 CPU 原因？

Answer 1

我想，核心问题是网络方面。如果您有 10,000 个链接和每个链接的 forkIO，那么您可能有 10,000 个套接字尝试一次打开，这取决于您的操作系统的配置方式，甚至可能都不可能，效率要低得多。

然而，我们拥有跨多个操作系统线程“虚拟”调度的绿色线程这一事实并不意味着我们可以随机分配工作而不考虑 cpu 使用情况。这里的问题不在于 CPU 本身的调度不会为我们处理，而是上下文切换(甚至是绿色切换)会花费周期。如果每个线程处理不同的数据，则需要将该数据拉入 cpu。如果有足够的数据，这意味着将东西拉入和拉出 cpu 缓存。即使没有，这也意味着将缓存中的内容拉到寄存器等。

即使一个问题是微不足道的平行问题，将它分解得尽可能小并尝试“一次完成”实际上也不是正确的想法。