sitr666

同样的需求。希望能够实现这样一种模型：brpc的每个io thread上实现run-to-completion模型，rpc call 不推到worker thread，把灵活性留个用户，用户可以自己控制什么时候切线程，控制线程的负载均衡，自己保证调用都是非阻塞的，这样用户能获得极致的性能，还可以在线程上集成N:1的协程。对于追求us级别极致延迟的服务很有用。 不知道这个模型在brpc中如何实现？brpc在线程模型的策略上是可以定制扩展的吗？有兴趣的朋友可以讨论一下。

> > 同样的需求。希望能够实现这样一种模型：brpc的每个io thread上实现run-to-completion模型，rpc call 不推到worker thread，把灵活性留个用户，用户可以自己控制什么时候切线程，控制线程的负载均衡，自己保证调用都是非阻塞的，这样用户能获得极致的性能，还可以在线程上集成N:1的协程。对于追求us级别极致延迟的服务很有用。 不知道这个模型在brpc中如何实现？brpc在线程模型的策略上是可以定制扩展的吗？有兴趣的朋友可以讨论一下。 > > 这个也许可以在启动的那个bthread上扩展一下bthread_attr_t，通过特殊flag让bthread原地运行。不过brpc整体上是为偏应用层面的场景设计的，如果是底层存储（如虚机云磁盘）或是高频交易等特别在意延时的场景，要冲击硬件极限估计有点困难，从epoll/kqueue直接开始写可能上限更高。不过，我也想说明一下，如果实际执行的worker代码不能做到完全异步（linux的IO就不行），其实在一个线程中从头到尾运行未必是最优的，也许在测试环境中不卡不拥塞时各种指标很好，但实际运行时不一定完全是这样。 谢谢回复，如果可以让bthread在指定的线程原地运行，不跨线程，是不是就相当于N:1的协程了？这的确和业务场景有关。RPC的Interface用起来还是很舒服省心的，从epoll开始写做到生产级别稳定好用也并非易事。业内有一些实践已经证明，用户态写裸盘可以做到完全无阻塞调用，在每个IO线程中集成run-to-completion线程模型，one loop per thread，很适合高性能低延迟的场景，毕竟一次nvme io已经不足10 us了，这个尺度下线程调度加上cache miss的综合开销显得就很大了。