覆盖阻塞的系统函数是不是可以获得更高并发？ about brpc HOT 10 CLOSED

是的，最早版本的bthread是覆盖usleep的。但覆盖毕竟是全局的，你很难保证所有的函数都不受影响，典型的就是TLS问题，出现一例程序就不正常了。另外也很难判断哪些函数的阻塞部分对性能比较敏感，哪些不敏感。更重要的是在RPC的场景中最主要的阻塞是网络交互，框架自己会管，肯定是不会阻塞worker pthread的，这部分阻塞至少占了80%-90%，所以去覆盖其他可能阻塞的函数既有风险又不是特别有用。gethostbyname更好的非阻塞替换方案是c-ares，不过在百度内dns很快，所以就一直没有换，开源后兴许会加上。

from brpc.

是不是这样理解假设一个 函数内部既有pthread阻塞又有bthread阻塞。 执行到pthread阻塞的部分，最高可同时pthread个数执行，执行到bthread阻塞部分，又可以自动切换成bthread阻塞，获得比pthread更高的并发，不用业务层去写额外的代码

from brpc.

是的。tcmalloc其实是个很好的例子，在bthread中tcmalloc仍然是可以使用的，因为tcmalloc内部没有显式地调用bthread接口，所有可能的阻塞都是pthread，没有TLS和死锁的顾虑。同时tcmalloc内的代码非常在意性能，如果我们把它用到的Mutex/condition什么的覆盖为bthread提供的，很可能做的更差了。

from brpc.

谢谢 非常好的框架，我们会尝试去使用，另外给个建议，外面中小型公司可能没那么大人力成本使用这些c++框架，如果能提供一个使用起来和php fastcgi fpm一样简单，又具有这些高性能特性的框架，必定会大火。

from brpc.

百度内部有，并且和brpc/hhvm有关联，未来也可能开源。

from brpc.

期待

from brpc.

@feimat 百度内部已经有基于brpc的php框架，性能比php-fpm高很多，未来也会开源。
另外关于你说的hook阻塞系统函数，我们其实也有实践，会有一些问题，比如hhvm在编译竞争时会有sleep调用，而且是不可重入的，这块不能被hook，又如gethostbyname之类的函数也是不可重入的。当然解决了这些case之后，还是能work的，至少在线上已经稳定运行一段时间了。

from brpc.

是的 我们现在的框架就是hook了，项目启动时 分别起n（n=2倍cpu核）个线程和m（m远大于n）个线程，每个线程里再起协程，对于普通io和能hook的代码块默认在n线程上跑，遇到不能hook的就切换到m个线程去执行（切换就一个函数），可新人会忘记切换到m线程的时候，影响就是同时只有n个并发，brpc刚好解决了这个问题，不需要手动切换pthread数

from brpc.

请问为什么hook函数的效率会比较差

from brpc.

主要是很多客户端 比如 mysql kafka等都是阻塞的, 这种就很烦

from brpc.