google / google/leveldb

Question: the safety of implementing a background compaction thread pool (1.20).

Open
#913 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
39.4k
Forks
8.2k
PR merge metrics
No merged PRs in 30d

Description

Hi all,
I have a question about the background compaction thread. currently, it only has one background compaction thread.

But in my use case, I have lots of db instances held by a process. I need the DB compaction of different DBs can run concurrently without queuing and wait for the other.

Is it safe to override the Env::Schedule interface, and put it into a different job queue, and let background threads deque?

As below diagram
```
+---> [queue1] -> bg thread 1 deque-> call func(arg)
|
Schedule() dispatch & signal --+----> [queue 2] -> bg thread 2 deque -> call func(arg)
|
+---> [queue 3] -> bg thread 3 deque -> call func(arg)
```

From the source code, it looks like the compaction job of a DB is mutually exclusive itself, and one db has one compaction job at a time. But I am not sure about this.

Grateful if you could advise

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.