youtao guo

I suppose we all agree that `std::string` is a bad abstraction to the bytes buffer data. But what is the most appropriate abstraction so that we can avoid data copy...

哪一个benchmark项目里挂掉的？我这里复现不了

看起来应该是wisckey的并发迭代器的锅，多线程导致的。 在主机的性能低下，迭代速度很慢时有很高概率触发。 问题定位在 `ConcurrenceDBIter `. https://github.com/coyorkdow/wisckey/blob/main/db/db_iter.cc#L166

看起来应该是wisckey的并发迭代器的锅，多线程导致的。 On Thu, May 19, 2022 at 13:08 王听正 ***@***.***> wrote: > 我删除掉原项目，直接从GitHub克隆（那么就是最新的主分支的代码）然后运行db_bench，又会出现不同的错误： > > db_bench: /mnt/b/Project/Clion/wisckey/db/vlog_fetcher.cc:38: leveldb::Status leveldb::vlog::VlogFetcher::Get(uint64_t, uint64_t, std::string*): Assertion `offset - my_info_->head_ < my_info_->size_' failed. > >...

请问op和brpc maintainer，是否有合适的方法得到一个bthread在被调度前wait的耗时？我们的服务也怀疑有这样的问题，但是苦于没有证据。

> 假定这里的设置都是默认的，done->Run()会让回调运行在独立的bthread中，done->Run()里只是创建。所以如果bthread不是特别多，且pthread在调用done->Run()时全程带锁，这里也不会死锁。但有一些设置可以让Done原地运行，这个要检查一下 请问一下是什么设置呢。 另外“done->Run()会让回调运行在独立的bthread中，done->Run()里只是创建”的意思是否是指done->Run()创建了新的bthread后直接返回，而不会join它。在这种情况下，即使新的bthread中去请求了mutex也不会死锁。因为pthread在done->Run()时不会被阻塞，可以之后把mutex释放，从而让bthread worker可以继续工作。 我理解在这个情况下确实不会死锁，但是如果done->Run()要等待这个bthread里的回调执行完，那还是会死锁的。