正在编写一个网络协议实现及其前端,主要是关于收发文件的。因为前端可能是 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 方面的函数。)
不知各位有没有更成熟的设计模式?
1
zhuangzhuang1988 164 天前 1
你这个很想微软的 APM 模型 https://learn.microsoft.com/zh-cn/dotnet/standard/asynchronous-programming-patterns/asynchronous-programming-model-apm
可以讲这种模型包装成 async await 的 |
2
weijancc 164 天前
偏个题, 我好奇你题中的 ArkTS, 搜了下有点难绷, 加了 3 个新特性就等于一门新语言了
|
3
w568w OP @zhuangzhuang1988 感谢推荐。我看了一下,好像和 MPI 的设计差不多:异步启动,创建一个 handle (&request ),后续靠这个 handle 去获取执行信息或者终止/等待任务运行。
@weijancc 严格来说 ArkTS 应该是一个框架而不是一门语言,所以和 Flutter 列在一起。当然,这不妨碍它烂,华为对 typescript node API 做的事和微信小程序对 javascript 生态做的事一样,主打一个添乱、阉割、碎片化。 |