这是一个创建于 130 天前的主题，其中的信息可能已经有所发展或是发生改变。
正在编写一个网络协议实现及其前端，主要是关于收发文件的。因为前端可能是 Dart （ Flutter ）、Swift 或 TypeScript （ ArkTS ），一方面不想重复造轮子，另一方面是 Dart 的性能不够高，实测相比原生，用 Dart 实现协议对传输速度有很大影响，所以决定把后端的协议实现抽象成几个 FFI 接口，用 C++ 或者 Rust 来写，包装成 .so，允许前端调用。
但是，因为目前想把协议库设计为直接处理各种网络（以及文件） I/O ，这些耗时操作必然不应该阻塞调用者的主线程（另外，Dart 和 TypeScript 开启新线程也很麻烦，不能要求他们去开）。如果要异步的话，我也不是很清楚具体怎么做比较好。
我目前的想法是，像 MPI 那样设计成：
call_something_nonblocking(&request)（不阻塞发起请求）wait_req(request)（阻塞到请求完成）get_req_status_nonblocking(request)（获取请求的进行状态）
或者是：
call_something(&request, callback)（回调式发起请求。跨语言传递回调是不是比较难实现？ TS 似乎不支持跨线程调用 ts 方面的函数。）
不知各位有没有更成熟的设计模式？
3 条回复 • 2024-07-17 13:51:50 +08:00
 |
1
zhuangzhuang1988 130 天前  1
你这个很想微软的 APM 模型 https://learn.microsoft.com/zh-cn/dotnet/standard/asynchronous-programming-patterns/asynchronous-programming-model-apm
可以讲这种模型包装成 async await 的 |
 |
2
weijancc 130 天前
偏个题, 我好奇你题中的 ArkTS, 搜了下有点难绷, 加了 3 个新特性就等于一门新语言了
|
 |
3
w568w OP @zhuangzhuang1988 感谢推荐。我看了一下，好像和 MPI 的设计差不多：异步启动，创建一个 handle （&request ），后续靠这个 handle 去获取执行信息或者终止/等待任务运行。
@weijancc 严格来说 ArkTS 应该是一个框架而不是一门语言，所以和 Flutter 列在一起。当然，这不妨碍它烂，华为对 typescript node API 做的事和微信小程序对 javascript 生态做的事一样，主打一个添乱、阉割、碎片化。 |
Select Language