我计划使用Apache Thrift，但有些调用会长时间运行/阻塞，但仍需要返回值，该值通常通过回调返回。
我了解 Thrift does not support 回调（这是否已更改？）所以我正在考虑让函数阻塞直到返回响应。这样可以吗？如果 RPC 请求耗时过长，Thrift 会抱怨（超时）吗？
他们说 Thrift 不适合双向通信，但使用套接字应该很容易做到。
上下文：我在本地的两个进程之间使用 Thrift 或 IPC，因此服务器上的负载不会很大，从而减轻了长时间运行的 HTTP 请求会使服务器过载的担忧。
我是否缺少其他东西提供的解决方案？
【问题讨论】：
标签： rpc thrift bidirectional
我了解 Thrift 不支持回调（这是否已更改？）
否（不支持）和否（未更改）。
一些调用会长时间运行/阻塞，但仍需要返回值，传统上会通过回调返回。
是的，如果您想坚持 RPC 的做事风格，或者在这方面受到技术限制。
所以我正在考虑让函数阻塞，直到响应 回来。这样可以吗？
长时间通话是完全合法的解决方案。当然，甚至轮询也可以是一种选择，除非您正在用呼叫淹没服务器。取决于“长”的确切含义。
如果 RPC 请求耗时过长，Thrift 会抱怨（超时）吗？
连接断开后，您始终可以发起新请求。
他们说 Thrift 不适合双向通信 但是使用套接字应该很容易。
在本地设置中，两端都充当客户端 和 服务器确实是可能的，并且在您的情况下可能是更好的选择。
相比之下，通过interblag 做到这一点要困难得多。因此，如果您有强烈的计划稍后将您的解决方案扩展到这样的场景，这可能会造成一些额外的麻烦，以便将 bidi 解决方案重写为长时间运行的调用。如果不是这种情况，您可以放心地忽略这一段。
【讨论】：