Add comment explaining coro threads
This commit is contained in:
parent
ac46992120
commit
ed35df9a00
|
@ -370,6 +370,16 @@ struct RocksDBKeyValueStore : IKeyValueStore {
|
||||||
std::unique_ptr<rocksdb::WriteBatch> writeBatch;
|
std::unique_ptr<rocksdb::WriteBatch> writeBatch;
|
||||||
|
|
||||||
explicit RocksDBKeyValueStore(const std::string& path, UID id) : path(path), id(id) {
|
explicit RocksDBKeyValueStore(const std::string& path, UID id) : path(path), id(id) {
|
||||||
|
// In simluation, run the reader/writer threads as Coro threads (i.e. in the network thread. The storage engine
|
||||||
|
// is still multi-threaded as background compaction threads are still present. Reads/writes to disk will also
|
||||||
|
// block the network thread in a way that would be unacceptable in production but is a necessary evil here. When
|
||||||
|
// performing the reads in background threads in simulation, the event loop thinks there is no work to do and
|
||||||
|
// advances time faster than 1 sec/sec. By the time the blocking read actually finishes, simulation has advanced
|
||||||
|
// time by more than 5 seconds, so every read fails with a transaction_too_old error. Doing blocking IO on the
|
||||||
|
// main thread solves this issue. There are almost certainly better fixes, but my goal was to get a less
|
||||||
|
// invasive change merged first and work on a more realistic version if/when we think that would provide
|
||||||
|
// substantially more confidence in the correctness.
|
||||||
|
// TODO: Adapt the simulation framework to not advance time quickly when background reads/writes are occurring.
|
||||||
if (g_network->isSimulated()) {
|
if (g_network->isSimulated()) {
|
||||||
writeThread = CoroThreadPool::createThreadPool();
|
writeThread = CoroThreadPool::createThreadPool();
|
||||||
readThreads = CoroThreadPool::createThreadPool();
|
readThreads = CoroThreadPool::createThreadPool();
|
||||||
|
|
Loading…
Reference in New Issue