V2EX › DinoStray 的所有回复 › 第 26 页 / 共 29 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 18 19 20 21 22 23 24 25 26 27 ... 29

❮

❯

2020 年 4 月 1 日

回复了 DinoStray 创建的主题 › 程序员 › 日志的格式化, 大家有什么最佳实践么

如果 {zookeeper} 可以节省我日后查询日志的工作量, 为什么我不一开始就用 {zookeeper}, 而是每次查询还得用一下转义那个[].
所以我的问题, 是日志格式化的最佳实践

2020 年 4 月 1 日

回复了 DinoStray 创建的主题 › 程序员 › 日志的格式化, 大家有什么最佳实践么

我的问题, 也不是怎样在 less vi 中使用转义, 而是日志格式化, 有没有什么最佳实践可以分享

2020 年 4 月 1 日

回复了 DinoStray 创建的主题 › 程序员 › 日志的格式化, 大家有什么最佳实践么

通过转义搜索, 我是知道的.
可是这样很麻烦, 比如我换成 {zookeeper}, 就直接搜 {zookeeper} 就好了.

2020 年 3 月 17 日

回复了 rsonghao 创建的主题 › Android › 500 以下安卓二手机求推荐

我这儿有一台 nexus 6p, 有两个月用作测试机, 闲置快 2 年了, 你要么, v 友 200 出了

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@jonah 我还一个问题暂时不知道怎么办, 不管服务端还是客户端, 我好像只能调用 TryCancel() 函数去主动关闭一个处于读写状态的 session, 更合适的主动关闭方式是调用哪个函数呢

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@jonah 我一直觉得用了智能指针就不能暴露裸指针了, 这两个东西混太容易导致程序崩溃. 我看 grpc 源码, 到处都是 unique_ptr 和裸指针的混用, 看的蛋疼

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@DinoStray 你的意思, 是每次调用异步 api, 都 new 一个新的对象, 新的对象封装了 session 和事件, 异步 api 回调的时候, 就可以通过这个对象知道 session 和产生的 event, 然后直接销毁这个临时的对象, 我的理解没错吧

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@jonah 你的这个封装, 和我把 session id + event 事件的解决方式, 是类似的, 不过有一点, 我的代码习惯用 C++11 智能指针管理, 不太想直接传递裸指针

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@jonah Sorry, 我看懂你的意思了, 你是做了第二层封装, 把 session 对象和状态封装到一起了

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@jonah 这个 demo 在同一时间, 只能读, 或者只能写, 要么写完了再读, 要么读完了再写. 在 bi-di stream 模型中, 我的需求是随机性有 N 个 request, 随机性有 M 个 reply, request 和 reply 没有任何关联

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@jonah bi-di stream, 是指同时开启异步的读写, 你这个 demo 依然还是把读写线性化了

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@jonah 再详细点说, 异步读和异步写都开启了, 这时候 completion queue 返回, 你可以根据返回的 tag 知道是哪个对象产生了事件, 可没有办法区分是读完成了, 还是写完成了

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@jonah 如果先读再写, 或者先写再读, 所有的事件基于线性产生, 那这个 demo 的模型的确可以跑通, 虽然实现有点繁琐. 可我的目标是 bi-di stream, 这时候就不适用了

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@jonah 读和写都是同步的, 不存在先后, 如果读写同步, 只能通过一个 completion queue 返回, 那你在对象成员里也没办法做区分了

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@icylogic 这个官方 demo , 如果同时做异步读写, 那这个 demo 的模型就跑不通了, 因为无法区分读完成和写完成

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@icylogic 这个 demo 我研究过了, 问题在于他没用 stream, 我的核心需求是实现 pubsub 模型, 所以必须用 stream, 基于一些设计, 还得是 bi-di stream

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@icylogic 官方 demo 就是个指针, 我的问题是, 如果用返回值标识指针, 就没办法区分事件类型了, 比如异步读和异步写

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@xkeyideal 我看了 java 和 golang 的 api, 实现都很简单易用, 唉

2020 年 3 月 11 日

回复了 DinoStray 创建的主题 › 程序员 › 忍不住想吐槽下 grpc 的 C++ async API

@codehz good idea.
可我刚刚发现自己转牛角尖了. 也许作者在设计这套 api 的时候, 就想让使用者每个 rpc 请求都有单独的 completion queue, 也就是最早的 "每个 tcp 连接一个线程" 模型. 我 epoll 用惯了, 思维方式固化了, 老是想着限制线程数量,

1 ... 18 19 20 21 22 23 24 25 26 27 ... 29

❮

❯