Woker 无法使用UThread所带来的好处

[nelsonjin]

个人认为这个RPC几个做的漂亮的地方：

1. IO流的处理
2. IO处理创新性的使用UThread，但仅限于socket -> data_flow(worker)之间

想问下， 有考虑Worker本身就是UThreadScheduler驱动吗？ 实际业务开发往往是Worker线程调用其他服务接口RT不可控导致 服务本身处理能力低下。这种异步IO，同步Worker解决不了这种问题。

worker能否改成是 UThread epoll 驱动的，而不是data_flow的队列消费驱动， 这样每个Worker线程都是一个UthreadScheduler，类似libco的思路， 便于Worker 在调用其他服务的时候使用 Uthread

Thks.

[lynncui00]

您好，你的建议非常好，但我们暂未添加这项功能主要有以下几点考虑。

1. 作为一个开源RPC框架，更多考虑到简单以及适用性，比如常用的中间件使用场景，下游调用是一些MYSQL类的数据库，那么多线程Worker是最合适的。
2. 而上下游都采用PhxRPC进行UThread化的调用，已经算是一个很系统性的工程了，需要系统的解决方案。

我们会考虑这个建议，适时支持Worker协程化。