Golang - 库是否需要非阻塞？答案

【问题标题】：Golang - do libraries need to be non-blocking?Golang - 库是否需要非阻塞？
【发布时间】：2013-07-24 23:24:03
【问题描述】：

我的理解是，如果非阻塞 Web 服务器（node.js、eventmachine、tornado）调用阻塞库，它们可能会停止运行。 Golang 也是这样吗？如果一个 goroutine 被阻塞，另一个 goroutine 是否会自动获得对 CPU 的访问权限，或者他们是否必须等待被阻塞的 goroutine 'yield'？如果是前者，那么库不需要是非阻塞的，不是吗？我问是因为我没有看到任何明确声明它们是非阻塞的 Redis/Mongo 库。

【问题讨论】：

标签： node.js go tornado eventmachine

【解决方案1】：

我的理解是非阻塞网络服务器（node.js，事件机器，龙卷风）如果他们打电话给阻塞库。 Golang 也是这样吗？

不，不是。 Go 例程将在 IO 上产生，或者运行时将根据需要创建新的操作系统线程。

如果一个 goroutine 被阻塞，是否会自动给另一个 goroutine 访问CPU

是的，go 例程会在任何类型的 IO 或通道通信上产生。

还是他们必须等待被阻塞的 goroutine 'yield'？

不，他们没有。

如果是前者，那么库不需要是非阻塞的，做他们？我问是因为我还没有看到任何 Redis/Mongo 库明确声明它们是非阻塞的。

没有库（或一般的 Go 代码）不需要非阻塞，这使得它们更容易编写和维护。在我看来，这是 Go 的一个主要优点。运行时会巧妙地运行 1000 多个 go 例程，而您只需编写简单的命令式代码。

【讨论】：

所以如果一个 goroutine 被阻塞，它不会阻塞整个线程（它与其他 goroutines 共享）？如果是这种情况，你唯一需要编写回调代码的时候是你希望那个特定的 goroutine 继续，而不是切换到另一个（我猜这很罕见）？
您不为此使用回调。你将把“阻塞的东西”放在一个单独的 goroutine 中，然后在它完成后使用通道来“回话”。
@Nick 你的三重否定很难理解，请澄清。（“没有图书馆……”）
很好的答案，尼克。异步 I/O 的当前时尚源于各种运行时的有限功能，尤其是 JVM。 Go 打破了特定的限制，让开发人员的生活变得更加轻松。（奥卡姆也有类似的意图）
@Tom，我认为他的意思是在否之后加一个逗号，即不，库不需要是非阻塞的。库可能会阻塞，因为即使一个 goroutine 阻塞，其他 goroutine 仍然可以访问 CPU。这与只有一个线程可以访问 CPU 的节点、事件机器、龙卷风等形成鲜明对比，因此永远不应该阻塞。