Support start KeepWrite bthread urgent

[chenBright]

What problem does this PR solve?

Issue Number: resolve #2588

Problem Summary:

What is changed and the side effects?

Changed:

Side effects:

• Performance effects(性能影响):

• Breaking backward compatibility(向后兼容性):

---

Check List:

• Please make sure your changes are compilable(请确保你的更改可以通过编译).
• When providing us with a new feature, it is best to add related tests(如果你向我们增加一个新的功能, 请添加相关测试).
• Please follow Contributor Covenant Code of Conduct.(请遵循贡献者准则).

[chenBright]

@wasphin 有空帮忙看看protobuf22缺失absl_flag库的问题

[wasphin]

absl 4038192a57cb75f7ee671f81a3378ff4c74c4f8e 中删除了 flags 库，当前使用的最新的 absl 20240116.1 没有 flags 库了，我看下怎么识别下依赖

[wasphin]

另外最新版的 protobuf（26.1）又改接口了，目前测 protobuf 22+ ci 安装的最新版的 protobuf，应该不久又会有问题🤦

[wwbmmm]

这个优化会有实际效果吗，如果启动了KeepWrite线程，说明之前的write已经写不进去了，这时再立即KeepWrite，是不是也会写不进去，最终还是要等待epollout

[chenBright]

不一定是写不进去。大多数情况应该是StartWrite写完队头数据，但是队列里还有还有其他数据，所以启动协程KeepWrite。

不过 #2588 在压力比较大的时候，整体服务能力都下降了。只优化少数连接上的rpc回包延迟，优化应该有限吧。

[chenBright]

另外最新版的 protobuf（26.1）又改接口了，目前测 protobuf 22+ ci 安装的最新版的 protobuf，应该不久又会有问题🤦

@wasphin 果然，又有问题了

[wasphin]

晚些我再下载个老版本 prootbuf.rb 吧，另外得看看后面 protobuf 怎么支持更新

[yanglimingcn]

不一定是写不进去。大多数情况应该是StartWrite写完队头数据，但是队列里还有还有其他数据，所以启动协程KeepWrite。

不过 #2588 在压力比较大的时候，整体服务能力都下降了。只优化少数连接上的rpc回包延迟，优化应该有限吧。

那如果是只写了一个req，队列里面还有其它数据，这种情况要是优化，可以让StartWrite去再取后边的请求，也不用再专门启动一个bthread吧。

[chenBright]

不一定是写不进去。大多数情况应该是StartWrite写完队头数据，但是队列里还有还有其他数据，所以启动协程KeepWrite。
不过 #2588 在压力比较大的时候，整体服务能力都下降了。只优化少数连接上的rpc回包延迟，优化应该有限吧。

那如果是只写了一个req，队列里面还有其它数据，这种情况要是优化，可以让StartWrite去再取后边的请求，也不用再专门启动一个bthread吧。

不可行吧。调用方的预期是写完自己的req就得返回了，后续还有其他逻辑执行。

[yanglimingcn]

不一定是写不进去。大多数情况应该是StartWrite写完队头数据，但是队列里还有还有其他数据，所以启动协程KeepWrite。
不过 #2588 在压力比较大的时候，整体服务能力都下降了。只优化少数连接上的rpc回包延迟，优化应该有限吧。

那如果是只写了一个req，队列里面还有其它数据，这种情况要是优化，可以让StartWrite去再取后边的请求，也不用再专门启动一个bthread吧。

不可行吧。调用方的预期是写完自己的req就得返回了，后续还有其他逻辑执行。

上面有个_write_head.exchange，这块如果fd有写的话，这个请求就挂到链表里面就返回了，下面的判断逻辑就不生效了吧？这块怎么理解呢？有时候起作用，有时候不起作用吗？

[chenBright]

我理解是要么同步写自己的req，要么异步写。

[yanglimingcn]

我理解是要么同步写自己的req，要么异步写。

那即使加这个start_urgent，也可能是异步写对吧？因为可能走不到这个分支就提前return了。

[chenBright]

我理解是要么同步写自己的req，要么异步写。

那即使加这个start_urgent，也可能是异步写对吧？因为可能走不到这个分支就提前return了。

是的

[yanglimingcn]

我理解是要么同步写自己的req，要么异步写。

那即使加这个start_urgent，也可能是异步写对吧？因为可能走不到这个分支就提前return了。

是的

那如果走到了下面的分支，说明本请求所在的线程获得了写的权限，它会把自己的请求写完，即使不启动start_urgent，启动start_urgent的目的是为了让后续的请求更及时的写到socket？

[chenBright]

期望是这样的，但是没测过效果。