Yang,Liming
Yang,Liming
> > > 不一定是写不进去。大多数情况应该是StartWrite写完队头数据，但是队列里还有还有其他数据，所以启动协程KeepWrite。 > > > 不过 #2588 在压力比较大的时候，整体服务能力都下降了。只优化少数连接上的rpc回包延迟，优化应该有限吧。 > > > > > > 那如果是只写了一个req，队列里面还有其它数据，这种情况要是优化，可以让StartWrite去再取后边的请求，也不用再专门启动一个bthread吧。 > > 不可行吧。调用方的预期是写完自己的req就得返回了，后续还有其他逻辑执行。 上面有个_write_head.exchange，这块如果fd有写的话，这个请求就挂到链表里面就返回了，下面的判断逻辑就不生效了吧？这块怎么理解呢？有时候起作用，有时候不起作用吗？
> 我理解是要么同步写自己的req，要么异步写。 那即使加这个start_urgent，也可能是异步写对吧？因为可能走不到这个分支就提前return了。
> > > 我理解是要么同步写自己的req，要么异步写。 > > > > > > 那即使加这个start_urgent，也可能是异步写对吧？因为可能走不到这个分支就提前return了。 > > 是的 那如果走到了下面的分支，说明本请求所在的线程获得了写的权限，它会把自己的请求写完，即使不启动start_urgent，启动start_urgent的目的是为了让后续的请求更及时的写到socket？
请问针对这种c++不同版本不匹配的问题，c++官方哪里有个统一的列表说明吗？想看看是否还有别的坑。
这个会有PR吗
请问去掉了bthread，polling模型下，用户的代码还能做到顺序执行吗？还是得实现callback这样的异步代码？
如果不想阻塞polling的线程，那看起来还是要走到协程这条路上来？有比bthread性能更好的方案吗？
关闭这个对监控指标会有啥问题吗？ 比如，curl http://xxx:port/vars
我理解在现有的M:N模型上，每个worker线程都运行一个非阻塞的epoll_wait或者其他的reactor，保证这个worker始终是运行着的，然后把signal_task这个功能禁用掉，其实就变成了bthread在一个worker上调度执行了。这时候steal_task就变成了一个被动的过程，一些worker确实空闲了就尝试去偷取一些其它worker上的任务。
感觉一般不会怎么使用，因为brpc已经提供了进程框架了，你是有什么别的需求吗？