vertx+jax-rs 绑定+kt coroutine 随便写写

我在关注一个方向——io_uring 生态的接入 目前给 netty 搞了一个 sendfile 的实现
netty 只是简单接入了对应的 poll 和 recv/send 没有做其他的 但是留了很多扩展点
所以我觉得基于 netty 的 io_uring transport 可以做更多异步生态 比如异步文件 io madvise 甚至还能把 ioctl 接进来
我目前搞了一个叫 Panamauring 的 repo 做这个事情

我也是有过这个问题 我的经历是:
idea -> idea remote ->wslg+idea->linux 真机+idea
其实如果你的配置够也不想搞双系统 可以尝试 wslg 直接把 idea 放进 linux 侧 这样不需要跨系统 io 也没有其他的问题

不太懂 arm ，target 是 armv7 的产物，能跑在 8 和 9 上吗？如果是 8 能跑在另外两个上面吗

https://github.com/jbellis/jvector java 向量化搜索引擎
https://github.com/softwaremill/jox kt channel 的算法移植到 java 实现
https://github.com/gunnarmorling/1brc 1b 行数据处理比赛
https://github.com/eclipse-vertx/vert.x 响应式应用构建工具箱

void 不是类型导致的一系列泛型问题
举个例子 future<Void>, 说到泛型怎么能不提提经典的 function ，intfunction 呢？🤣
还有典中点只 arrays.sort 的各种重载
最后就是元编程能力，编译期 or 运行时元编程能力太弱 坐等 code reflection 实现，你可能说这跟我写 spring 有什么关系，请参考升级 jdk 但是不升级 spring 导致的 asm 版本问题 更何况 spring 自己依赖的 cglib 原始版本都没跟着版本兼容，还是 spring 自己魔改的，唉，要是 class file api 早点出来会有这事?
好特性出的太晚，远水解不了近渴
再吐槽下 openjdk group 对延迟到运行时 or 第一次使用时带来的冷启动问题，很多玩意本来就可以编译期搞定，结果一定要延迟到运行时，很多极其依赖于 jit ，说的就是你 lambda 和 switch!最后又得搞个 Leyden 擦屁股

👀我理解如果每个新 sb 项目都要这一套的话 是不是有个抽一个 starter 来自动配置呢？

@pursuit The execution state of the request has progressed far enough that cancelation is no longer possible ，不保证吧。。。

能请问下 io cancel 适配是卡在 io_uring 并不保证 cancel 成功吗？🤔我之前遇到的就是这个问题，在写场景/读场景 若未取消成功即操作已经推入内核执行的情况下 用户操作对应到那块内存就会产生 ub

这个版本 native image 支持新 ffi api 虽然只有 downcall 但也不错了，gu 支持被移除改为在构建工具脚本里面声明对应组件，简直是重大利好
新的 o3 优化等级从 spring petcline 测试来看和 graalvm ce jit 模式不相上下，还不错
https://medium.com/graalvm/graalvm-for-jdk-21-is-here-ee01177dd12d

virtual thread 目前 public 的 api 都太简单了，不如 kt 可以微操调度，所以我还搞了这个玩意 https://github.com/dreamlike-ocean/UnsafeVirtualThread ，来搞手操调度，指定调度器，捞 carrierThread
virtual thread 好处对我来说有两处:
1,是沟通 Reactive 到 Blocking 的桥梁，我可以低成本来复用老的 BIO 生态，比如我就喜欢开虚拟线程跑 jdbc+myabtis/hibernate,比 hibernate reactive 好用多了
2,我可以低成本将异步转同步，比如说 Future.await ，直接捞 continuation api 起来自己做调度也很好玩，对于 reactive 生态来说就无需引入 kotlin ，也无需被无栈协程的染色效应困扰

@furaoo 没做边界处理。。。设计个定界的协议吧 如果是能确定固定长度直接用 fixlength 的那个 codec ，如果没有报文中没有特殊符号也可以按特殊符号分割，或者直接做在头部放 body 长度的协议，不要依赖于裸的 channelread 行为

不知道你的 encoder 和 decoder 咋写的，感觉是因为没有正确处理流边界发生的

@echo1937 对目前 pg 和 oracle 都做了，MySQL 没动静 但是 MariaDB 是可以兼容的

gitbook 本地写完推上去自动生成
一开始是和学弟妹一起写简洁 web 开发教程的顺便教教他们怎么 git 协作，想写点不一样的东西
后面我单独给自己开了一个小模块写自己看到的好玩的东西
https://dreamlike-vertx.gitbook.io/qing-you-hou-duan-xiao-ce/

先做热点采集 jfr 打个火焰图看看
再分析下 perf 没数据不知道该怎么处理 也不清楚是什么样子的业务
如果是那种你依赖的服务响应非常慢 直接上 reactive 来做 io 所占的也就几个闭包的内存，然后善用 timeout 和 buffer 来做被压就好了

如果是依赖于 cpu 嗯算 那基本只能叠机器了 这种一般采集完信息会显示 cpu 占用平均值非常高

@byte10 我提到的 continuation api 是一个内部 api 我也是通过一个非常“邪恶”的方法来拿出来用的 如果不在乎升级的阻力 这个可以直接用我的方案。。。
否则还是 kt 那个靠谱

@byte10 continuaion 有俩原语，yield 将控制权返回给调用方，resume 从上一次 yield 的位置继续执行，java 基于这个玩意实现的有栈协程，单独拿出来用就是自己搞调度，可以参考我写的这个库的实现 https://github.com/dreamlike-ocean/UnsafeVirtualThread/blob/master/vertx-ext/src/main/java/top/dreamlike/AsyncScope.java

loom 当前的情况似乎并不适合用 vertx ，kt corotinue 会更适合一些
只有当 loom 解决了 sychronized 等问题 或者 旧生态中逐渐兼容了这些问题 在 vertx 中使用 loom 才有一些优势
目前使用 virtual thread 相比 kt corotinue 的优势只有适合保存完整堆栈信息