multithreading - 有没有办法杀死 GHCi session 中的所有 fork 线程而不重新启动它？

Question

基于 my previous question我想问一下是否有任何方法可以杀死 GHCi session 中所有用户创建的线程？

这样做的原因是当一个函数在 GHCi 中退出时，它产生的线程不会自动终止，即使重新加载代码也会持续存在。重新启动 GHCi 解决了这个问题，但由于我的应用程序需要一段时间才能加载，如果有可能(甚至是 hacky)的解决方法，那就太好了。

Answer 1

不，实际上与 How can I build a ThreadId given that I know the actual number? 中的原因几乎相同: 图书馆根本不给你任何东西来获得 ThreadId s 所有(仍在运行的)线程或任何其他工具来处理不属于您的任何线程。

此外，您无法可靠地猜测 forkIO 产生了哪些线程。属于您的 GHCi session (所有评估通常在 forkIO 中进行沙盒处理)、底层 yesod 应用程序或线程 RTS(至少有一次调用 forkIO - 这基本上确保所有事件管理器都被关闭) .目前，这还不错，因为 GHCi 在 main 中运行。如果无论如何关闭，线程和 IO 管理器会重新启动，但这可能会在 future 的版本中改变。

那么为什么线程甚至在终止时被收集呢？ hs_exit() .本质上，它调用 ioManagerDie() (杀死所有 event managers )和 exitScheduler(..) (见 scheduler ，基本上是 kills all threads 。这些函数都没有适当的 FFI 包装器。

当时hs_exit()被称为 main来自 Haskell 世界的已经完成了。因为这些函数在 GHC.* 中都没有适当的等价物。模块，你不能直接在 Haskell 和 GHCi 中调用它们，因为没有合适的 :#命令。

所以总而言之，你不能。如果在 GHCi 中添加一个重新启动调度程序的命令，那将很容易。但是鉴于调度程序在 hs_init() 中启动并停在 hs_exit()在 RTS model ，我怀疑这将是一个简单的扩展。

但是，根据您想做什么，您可以作弊。你可以自己写forkIOMem ，其中存储 ThreadId在全局MVar , 并替换所有 forkIO在来源中。这可能非常麻烦，尤其是在您使用库时，因为您需要确保 forkIO到处被替换。

当然，您可以干预 base包，但这可能很疯狂(尽管仍有可能)，更改forkIO在那里并添加killAllforkIOs至Control.Concurrent . (我已经说过这可能是疯了，对吧？)