想换一条和现在完全不同的路走

和管家联系，我同事成功让管家给升级宽带了

@hello2060 extremeDB?

第三家说的不是读写锁么。。。。。

我一般直接用 curl 来做

上海的麻辣烫木有麻酱
上海小资氛围浓郁, 各种精致的商店. 不过这一点对 IT 宅男应该可以忽略
上海和北京, 本地土著都有强烈的优越感, 会排外
上海木有暖气, 白天或者在室外都还好, 晚上睡觉我会难受. 有钱人买个电暖气应该可以解决

@chendy 可是有些内容, 还是给开发者看的, 不管开发过程定位问题, 还是线上故障分析. 这类给开发者看的日志, 有没有什么好的, 更易读的最佳实践

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

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

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

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

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

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

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

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

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

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

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