0xFFFC0000

> @0xFFFC0000 is correct in that a reader lock is necessary to access the db, since another function could modify the pointer, etc. Although that doesn't seem to happen often,...

> > It is not about the pointer. Take a look at the example I provided to rbrunner, or look at the code. > > You added locks where none...

> I've written this before but I'll also add a comment here. There was or is an issue where the daemon would fall behind if there's really heavy RPC traffic....

> Sorry for spamming - `::scan_outputkeys_for_indexes` was one such example I was thinking of. No worries. We are evaluating a serious PR, and these discussions are normal. Yes `scan_outputkeys_for_indexes`, that...

> > It is not about the pointer. Take a look at the example I provided to rbrunner, or look at the code. > > You added locks where none...

Updated the implementation of `reader_writer`. Changelog: 1. Rebased to master and added recent changes from the master. 2. Adding a queue to keep the order of operations. Reads are parallel,...

> I took a quick look at the code and I don't see any issues (yet). I'll check more thoroughly later. What would be really nice, is if the unit...

> I think it's better to separate it to another executable. > > But you can try to hack CMakeLists.txt with something like > > ``` > > if (CMAKE_CXX_COMPILER_ID...

> Gtest doesn't provide a timeout, but you can set the timeout in .yml files for the CI in https://github.com/monero-project/monero/tree/master/.github/workflows Yes. I agree with you. Separate binary is more preferable...

> Looks like this implementation still suffers from reproducible writer starvation (though I haven't debugged the reason this time). Here's a test case I wrote for it: [jeffro256@3ae55c6](https://github.com/jeffro256/monero/commit/3ae55c6b85157886b86e303b8ae6701584e1149d). I wrote...